· 阅读需 64 分钟
Cover Picture


2023 2月

Ibrahim Haddad 博士

战略计划副总裁(AI 和数据)

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



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



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



“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.



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

Be patient and seek out influential peers when growing your domain expertise, open source methodology, and working practices.Practice and encourage an open and collaborative mindset when implementing open source infrastructure.Adopt IT infrastructure that is flexible and supportive of open source development.
在发展领域专业知识、开源方法和工作实践的同时,要有耐心并寻找有影响力的同行。在实施开源基础架构的过程中,实践并鼓励开放和协作的思维模式。采用灵活且支持开源开发的 IT 基础设施。
Track success through specifically designed metrics for an open source environment.Follow a lightweight and tailored approach to source code contribution approvals.Share information across divisions and foster internal collaborations for successful implementation of innersource practices.
Contribute strategically to projects that are commonly used across products and services to remain essential, justifiable, and fundable.Allocate time for open source developers to meet upstream responsibilities, especially if they are maintainers.Partner with product teams on upstream code development that helps reduce their technical debt.
Develop open source talent internally, and encourage involvement in open source from developers across the organization.Create a mentorship program to support the growth of junior developers and increase the quality and quantity of code accepted in open source projects.Participate in and host open source events to build developer networks, participate in technical discussions, and increase visibility.



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



  • 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





Development model
IT infrastructure
Executive education
Development tools
Knowledge transfer
Metric tracking
Technical training
Knowledge sharing
Compliance training
Team formation
Code reuse
Executive support
Mentorship programs
Hiring practices
Software composition analysis
Success metrics
tool adoption

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





  • 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


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.


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.


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





  • 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


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


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.


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




  • 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.

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



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




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


  • 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







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







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



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的宝贵评论和反馈表示衷心的感谢。从他们的 经验、评审和贡献中,本报告受益匪浅。



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


• 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

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月。

· 阅读需 142 分钟


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 基金会

Info Graphic

5.1 Average number of outstanding, critical vulnerabilities in an application. Ranges between 2.6 and 9.5 based on programming language.24% of organizations are confident in the security of their direct dependencies.59% of organizations report their OSS is somewhat or highly secure.
5.1 平均每个应用程序存在的重要漏洞数量。 根据编程语言的不同,重要漏洞数量的范围在 2.6 到 9.5 之间。24% 的组织对它们的直接依赖的安全性感到有信心。59% 的组织报告称,他们的开源软件在一定程度上或高度安全。
68.8 Average dependencies per project. Ranges between 25 and 174 based on programming language.18% of organizations are confident in the security of their transitive dependencies.SCA and SAST tools are the #1 and #2 tools used to address security concerns.
68.8 每个项目的平均依赖项。 根据编程语言的不同,依赖项的数量在25到174之间变化。18% 的企业对其传递依赖项的安全性感到有信心。软件组成分析(SCA)和 静态应用程序安全测试(SAST)工具是解决安全顾虑使用的排名第一和第二的工具。
97.8 Average number of days it takes to fix a vulnerability.49% of organizations have a security policy that addresses OSS.73% of organizations are searching for best practices to improve their software security.
97.8 平均修复漏洞所需的天数。49% 的组织拥有涵盖开源软件安全的安全策略。73% 的组织正在寻找提高软件安全性的最佳实践。
Increased incentives by employer is the #1 approach to improving OSS resourcing.More intelligent tools are the #1 way organizations intend to improve supply chain security.11% Average increase to an organization’s security
score in 2022.
雇主提供更多的激励措施是改善开源软件资源配置的第一途径。更加智能的工具是组织机构试图提高供应链安全性的第一选择。11% 组织在2022年的安全分数平均提高百分比



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.


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

Figure 1: Organizations with a security policy covering OSS


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




不知道(英文应该是错了,坐标轴上是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

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




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.

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

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?


Weighted Avg of responses
Score range: 0 -100





Highly Insecure:

Somewhat Insecure:

Neither Insecure or Secure:

Somewhat Secure:

Highly Secure:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

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?


Figure 4

Weighted Avg of responses
Score range: 0 -100





Highly Insecure:

Somewhat Insecure:

Neither Insecure or Secure:

Somewhat Secure:

Highly Secure:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

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

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?





Security team and /or CISO:

Multiple teams:

Open source maintainers:

No one:

Developer or care contributor:

Operations or Bite Reliability Engineers (SREs):

Contributors from other teams:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

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.


Figure 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?




Source: 2022 Open Source Supply Chain Security Survey.

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

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


Source: 2022 Open Source Supply Chain Security Survey.

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

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:按语言和严重程度划分的平均漏洞数量

Figure 9

Vulnerability Severity






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.


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

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


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.


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.


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.


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

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

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

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


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.


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.


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.


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.


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.


Figure 13

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?


Figure 14

Software Composition Analysis (SCA) tools

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)


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.


  • 有多种来源可以确定评估项目本身的最佳实践/认证。这包括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)


Figure 15

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
全球唯一标识特定软件组件 / 发布版本


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.


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 行业组织可以提高开源软件开发安全性的方法?(选择所有适用项)

Figure 16

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.


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

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

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%重新分配给有价值的开源项目


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.


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.


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.


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 的可持续性 如果项目的维护者决定退休,应如何解决开源软件的可持续性问题?(选择所有适用项)

Figure 18

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


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.




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 年的经验,他的职业生涯始于帮助台运营,多年来不断发展到更复杂和多样化的角色。在过去的七年中,马丁已经开发了将数据转化为情报的技能,并将 “极客语言” 翻译成普通人可以理解的语言。



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)。



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 基金会及其作者、贡献者和赞助商均不对任何其他方因与本报告有关的任何形式的间接、特殊、偶然或后果性损害负责,无论是基于合同违约、侵权(包括疏忽)还是其他原因,并且无论他们是否已被告知可能出现此类损害。赞助本报告的创建不构成任何赞助商对其调查结果的认可。

Back Cover

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。

· 阅读需 125 分钟

Front Cover

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


In partnership with 合作作者

Contents 目录

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
About the author..................................................................................25
信息图:LFX 导师计划..............................................................4
关于 LFX 导师计划的研究...........................................................5
概述:导师计划希望解决的问题 .......................................................6
LF 导师关系的起源.................................................................9
导师计划的挑战 ..................................................................16
导师计划的职业价值 ...............................................................18
结论 ..........................................................................22
  可操作的见解 ....................................................................22
方法论 .........................................................................24



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


Infographic: LFX Mentorship program


Front Cover

Mentorship creates opportunities for a healthy succession of open source project contributions and leadership.Mentorship encourages greater equity and accessibility for underrepresented groups to engage in open source projects.87% of mentees are students, 86% already participate in open source, and 88% are involved in IT broadly.
导师计划为开源项目建设及社区领导力的良性迭代进行了支撑和创造了机会导师计划鼓励弱势群体参与开源项目,以保障开源项目的公平性和可及性。87% 的辅导对象是学生,86% 已经参与了开源,88% 或多或少的涉及和使用IT技术。
67% of mentees had never been paid for their open source involvement prior to beginning the mentorship.Before completing the progam, 64% of mentees lacked some degree of confidence in their ability to engage in open source.69% of mentees have seen their career advance because of mentorship, with 47% saying that the program helped them get a job.
在接触导师计划之前,67% 的学员从未因参与开源而获得过报酬。在完成指导之前,64% 的辅导对象对他们参与开源的能力缺乏一定程度的信心。69% 的辅导对象因为指导而看到了他们的职业发展,47% 的人表示该计划帮助他们找到了工作。
67% of employed mentees report an increase in their income after the program.52% of the mentees who are now employed are getting paid for their open source involvement.99% of former mentees recommend the program to others, and everyone involved says that the program was beneficial.
67% 的在职辅导对象表示他们的收入在参与该计划学习和指导后有所增加。52% 的在职辅导对象因参与开源项目而获得报酬。99% 的前学员向其他人推荐了该计划,所有参与人员都表示该计划受益匪浅。
90% of mentees have increased confidence in their ability to contribute to open source compared to before they started the program.85% of mentees are or are willing to continue contributing to the project they were involved in after mentorship.One of the program’s challenges is recruiting mentees with the essential skills for open source development.
与开始该计划之前相比,90% 的辅导对象对自己为开源做出贡献的能力更有信心。85% 的辅导对象正在或愿意在接受指导后继续为他们参与的项目做出贡献。该计划的挑战之一是招募具备开源开发基本技能的学员。

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?


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 正在积极尝试通过让代表性不足的群体社区的成员参与进来,包括那些经济条件较差的人,来改变这个现状。


Figure 1图 1
What group or class do you identify with?你属于跟他组或者等级?
10.6% Prefer not to answer10.5% 不想回答
19.7% Working Class19.7% 工薪阶层
0.4% Upper class0.4% 上等收入
16.9% Upper middle class16.9% 中上等收入
52.4% Lower middle class52.4% 中下等收入

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.


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.


Figure 2图 2
What was the name of the mentorship project you worked on?你参与的辅导项目是什么名字?
CNCF projectsCNCF 项目
Linux kernel bug fixingLinux 内核错误修复
Open Mainframe开放主机
Hyperledger and blockchain projects超级账本和区块链项目

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.”


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.


“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,


“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,


“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:


“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.”


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.



Figure 3图 3
Before the mentorship program, which of the following best describes your level of confidence with respect to engaging in open source?参加导师计划之前,以下哪项最能描述您对参与开源项目的信心程度?
Not confident不自信
Somewhat confident有一些自信
Very confident非常自信
Extremely confident极其自信

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.



Figure 4图 4
After completing the mentorship program, which of the following best describes your level of confidence with respect to engaging in open source?在完成指导计划后,以下哪项最能描述您对参与开源的信心程度?
Prefer not to answer不想回答
Stayed the same保持一致
Decreased significantly极大地降低了
Increased significantly提升幅度很大

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,


“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:


“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.”


Mentorship can provide these individuals with the skills and knowledge to succeed. Khan elaborates,


“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.”


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:


“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.”


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.



Figure 5图 5
Are you willing to contribute to the project you were mentored in?你愿意为你所指导的项目做出贡献吗?
Yes, and I have been since completing my mentorship是的,自从完成我的导师计划以来我一直在做贡献
Yes, I would be willing to continue contributing to the project是的,我愿意继续为该项目做出贡献
No, I am currently unable to commit time to the project不,我目前无法为该项目投入时间
No, the project no longer overlaps with the work I do不,该项目不再与我所做的工作有交集
No, there are other reasons I can't continue working on this project不,还有其他原因我不能继续从事这个项目
Prefer not to answer不想回答

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.


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.1 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.2

问题不一定是缺乏技术专业人员。根据美国国家教育统计中心的数据,美国大学授予的计算机科学和信息技术学位比例在经历了一段时间的下降后出现反弹,2020年占所有学位的近5%。1 根据美国劳工统计局的数据,预计所有计算机和数学相关工作的就业人数在未来十年内将增长 15%。2

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.)


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.


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.


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).


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.



Figure 6图6
Before the mentorship program, did you receive financial compensation for your contributions to open source projects?在参加导师计划项目前,你收到过开源项目贡献的经济补偿吗?
Prefer not to answer不想回答
No, I did not receive financial compensation不,我未曾收到过经济补偿
Yes, but not enough to cover my living expenses是的,但不足以满足我的生活开支
Yes, enough to cover my living expenses是的,且足以满足我的生活开支
Yes, my compensation was more than enough to cover my living expenses是的,且薪酬在支付生活开支后有结余


Before and after completing the mentorship program, what best describes your involvement in open source technology projects?在完成导师计划项目之前和之后,哪一个最能描述您参与开源技术项目的状态?
Before mentorship导师计划前
After mentorship导师计划后
Full-time student全日制学生
Part-time student非全日制学生
Salaried employee带薪职工
Working full time above minimum wage高于最低工资的全职工作
Working part time兼职工作
Vounteer(full or part time)志愿者(全职或兼职)


Figure 8图8
If currently employed, has your income increased following your participation in a mentorship program?如果目前受雇,在参与导师计划项目后你的收入是否增加?
Prefer not to answer不想回答


Figure 9图9
Did your mentorship program help you to advance your career (e.g., you received a promotion, a raise, or found a new job with greater opportunities)?你的导师计划是否有助于你的职业发展(例如,使你获得了晋升、加薪或找到了机会更大的新工作)?
Yes, my career has advanced是的,我的职业有所进步
Not yet还没有
Not yet, but I have new oppotunities to do so because I was a mentee还没有,但是因为我曾是学员,我有新的职业发展机会
No, I have not been able to advance my carrer不,我的职业发展没有进步


Figure 10图10
Did your mentorship program help you to find a new job? When did you complete your mentorship program?你的导师计划是否帮助你找到了一份新工作?你什么时候完成导师计划的?
No, but I am looking for a job还没有,但我正在找新工作
No, I am not looking for a job还没有,我没在找工作
No, I was already employed不,我已经就业了
Prefer not to answer不想回答


FIGURE 11图11
Before and after completing the mentorship program, what best describes your involvement in open source technology projects? Are you currently employed?在完成导师计划之前和之后,哪一个最能描述您参与开源技术项目的状态?您当前是否就业?
Before mentorship导师计划前
After mentorship导师计划后
After mentorship and currently employed导师计划后且当前已就业
Volunteer in OSS开源软件志愿者
Observing OSS projects观察开源软件项目中
Working full time in OSS全职投入开源软件项目
Working part time in OSS兼职投入开源软件项目
Not partcipate in OSS没有参与开源软件项目

“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.


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.



Figure 12图12
What statement below best describes the benefit you derived from your mentorship program? (select all that apply)以下哪项陈述最能描述您从导师计划中获得的收益?(选择所有适用项)
Completing the program provides me useful experiences and references完成该计划为我提供了有用的经验和参考
I see significant benefit from the program in helping me find and succeed in future jobs我认为该计划在帮助我找到未来工作并取得成功方面有很大的帮助
Completing the program was transformative to my career and employment opportunities完成该计划对我的职业生涯和就业机会产生了变革性影响
I see some benefit from the program in helping me find and succeed in future jobs我认为该计划在帮助我找到未来工作并取得成功方面有一些好处
I see significant benefit to my current job我认为对我当前工作有巨大好处
I see some benefit to my current job我认为对我当前工作有一些好处
I didn't see any benifit我没有发现任何好处
58% of participants believe the program had both a significant and transformative impact on their careers.58%的参与者相信导师计划对他们的职业生涯产生了巨大的和变革性的影响


Figure 13图13
Would you recommend the mentorship program to others?你会向他人推荐导师计划吗?
Prefer not to answer不想回答



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.


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?


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.


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.


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.


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网络研讨会方面的宝贵经验。



  • 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%



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%在信息技术行业工作。

Figure 14
Mentorship class指导班级
Location during mentorship指导期间所在位置
Asia Pacific亚洲太平洋
Industry of employment就业行业
Other industries其他行业
Information Technology (IT vendor or sevice provider)信息技术(IT 厂商 或 服务提供商)

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年起涵盖企业技术。



作者希望感谢我们的赞助商,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导师,尤其是本次研究的受访者。



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.




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名新的开发人员。我们的一些毕业生现在已经稳定就业,并继续为开源项目做出贡献。我们坚信并致力于为所有背景的新开发人员提供学习路径。

LF Research

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.


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)托管的全球合作项目,包括金融、银行、物联网、供应链、制造业和技术领域的领导者。在技术治理和开放合作的基础上构建,鼓励个人开发者、服务和解决方案提供商、政府协会、企业会员和终端用户参与开发和推广这些具有改变游戏规则的技术。

Training and Certification

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.


Open Mainframe

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.



  1. National Center for Education Statistics. 2022. Undergraduate Degree Fields. Condition of Education. U.S. Department of Education, Institute of Education Sciences. Retrieved 11/23/2022, from (https://nces.ed.gov/programs/coe/indicator/cta). 2

  2. U.S. Bureau of Labor Statistics. 2022. “Computer and Information Technology Occupations: Occupational Outlook Handbook”. Retrieved 11/23/2022, from (https://www.bls.gov/ooh/computer-and-information-technology/home.htm). 2

· 阅读需 122 分钟

Front Cover

OSPO 的商业价值

An Exploration of Why Organizations Create, Sustain, and Expand Open Source Program Offices (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


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作序


Forewords ............................................................................................................................................3
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
What’s coming in the future? ............................................................................................................................................21
Future research....................................................................................................................................................................21
About the authors .............................................................................................................................................................. 22


序 ................................................................................3
为何我们关注OSPOs的商业贡献? ..................................7
独特故事的共同脉络 ................................................7
方法论 .............................................................8
克服内部阻碍:文化和教育 ..............................................16
与开源之间的战略关系 ...................................17
OSPO的不同角色 ..................................18
顾问 .................................18
常见的OSPO KPIs ..........................................................19
KPI搜索................................................................. 20
展望未来 ......................................................21
关于作者 ..................................................................... 22


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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

OSPOs are built to help students and researchers create and advance open source projects for widespread useOSPOs are used to produce knowledge for social good through open access to researchOSPOs drive compliance, standardization, reputation, knowledge sharing, development speed, security, and sustainability
Many OSPOs start by cleaning up past ad-hoc open source effortsThe most common internal OSPO challenges include culture, education, defining and measuring successThe top KPIs that OSPOs measure include sustaining contributors and project success
Tracking project health – including commits, maintainers, and contributor activity and diversity –is essential for sustainabilityOSPOs can help to turn projects from cost centers to profit centersThe most common OSPO skill sets include counselor, facilitator, environmentalist, and advocate

OSPO 的商业价值

建设 OSPO 旨在帮助学生和研究人员创建并推进开源项目,使其被广泛应用通过开放研究,OSPO 可以用于创造社会公益知识OSPO 推动 企业的合规性、标准化、声誉、知识共享、开发效率、安全性和可持续性
OSPO 对学术的价值OSPO 的学术动机OSPO 对企业的价值
许多 OSPO 项目始于清理过去的临时性的开源工作最常见的内部 OSPO 挑战 包括文化、教育,以及对 OSPO 的定义和成功的度量度量 OSPO 的首要 KPI 包括持续贡献者人数和项目成功与否
最小可行的 OSPOOSPO 的挑战OSPO 的度量方式
跟踪项目的健康度 – 包括代码提交者、维护者以及贡献者的活跃情况和多元性 –这对可持续发展至关重要OSPO 可以帮助企业,将项目 从成本中心转变为利润中心最常见的 OSPO 技能分工包括 顾问、推动者、环境保护者, 以及布道者
OSPO 度量方式企业 OSPO 的可持续性OSPO 的角色



Why do we care about how OSPOs contribute to the business?


A well-designed OSPO is the center of competency for an organization’s open source operations and structure.


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.


“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.


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.


“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



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:


  • 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.


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.


“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.


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.”


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.


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.


“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.


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.


“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.


“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提到他加入之前公司的情况时说。没有人认为它们是非常成功的项目。他说:“我认为他们对自己的成功没有清晰的认识。”



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.




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.


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.


“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.


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.


Who starts the OSPOs?


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.


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.


“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.


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”


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.


“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.




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.


“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?


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.


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.




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.


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


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.


“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.


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.


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.


“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.


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.”


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.


“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.


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.


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


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.1

连续性对组织来说是持续的挑战,因为它们要适应业务,竞争环境和更大的技术生态。根据 Linux 基金会的白皮书《深入开源办公室》,开源办公室需要建立清晰、简单的汇报流程,并确保与所有利益相关方保持沟通渠道畅通。维护开源办公室内部支持对于确保组织继续按照其商定的开源战略和能够在开源项目和优先事项上至关重要。1

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


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 2 to help develop better metrics for OSPOs to measure their own success.

也有一些联合项目来确定要跟踪的最佳指标: TODO 小组和 CHAOSS 创建了 OSPO 指标工作组2,以帮助为 OSPO 制定更好的指标,衡量其自身的成功。

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 成熟度模型 (开源博客文章解读)



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的合伙人,专注于指导、建议和投资开源和基础设施创业公司。









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.


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.


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 所著的前言。


  1. A Deep Dive into Open Source Program Offices 2

  2. https://github.com/chaoss/wg-ospo 2

· 阅读需 216 分钟


How Open Source Leaders Are Confronting the Challenges of Fragmentation


January 2023


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




[Infographic 3]

[信息图表 ..............................................................3]

[Foreword 4]

[前言.................................................................. 4]

[Executive Summary 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]


[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]


[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]

Fragmentation is a double-edged sword, where attempting to solve fragmentation challenges could hurt innovation and competition.
There is considerable heterogeneity in the software landscape when it comes to fragmentation: Some domains are highly fragmented, and some are highly consolidated.
The principal downsides of fragmentation include increased costs and complexity for consumers and vendors of open source solutions.
Once firmly rooted in the United States and Western Europe, today’s open source community is increasingly global and cosmopolitan.
Language, culture, and geopolitics remain barriers to participation in open source communities.
Diversity and inclusion are critical to building a robust open source talent pool.
Techno-nationalism poses a severe threat to open source collaboration, with geopolitical tensions creating regional silos in global innovation communities.
Transparent open source development protocols are the best antidote for techno-nationalism.
The creation of new open source projects has seen a comparable increase in the number of new foundations.
Ecosystem leaders want foundations to do more to align open source projects that have similar objectives.
Securing and safeguarding critical open source infrastructure should be a focal point for collaboration.
The need for enhanced collaboration extends to a range of Internet governance issues, including cybersecurity, intellectual property, and antitrust.

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 国际公共许可证授权。



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.


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.


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?


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.


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.1 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上贡献最多的用户。1 然而,中国并不是唯一的例子,许多新兴经济体都有庞大的开源开发者社区,包括印度、俄罗斯、韩国和乌克兰。对于低收入和中等收入国家来说,与开源社区的接触正在催生新的企业家精神,并加速经济发展的步伐。

  5. 语言、文化和地缘政治仍然是参与开源社区的障碍。 虽然开源技术在全球范围内蓬勃发展,但北美以外的开源项目领导者指出语言、文化和地缘政治确实是影响他们最大化吸引才华横溢的开发者参与的障碍。虽然开源社区越来越国际化,但一些领导者认为总部位于美国的组织在塑造大多数开源项目方面具有不可忽视的影响力。开源领导者担心,如果不能解决多样性和包容性问题,将会限制开源社区获取人才和创新的能力。

  6. 多样性和包容性对于建立强大的开源人才库至关重要。 将不同语言和文化融入开源社区的挑战并不是新问题,生态系统有很大信心能够促进全球包容性。然而,开源领导者认为社区可以采取更多措施促进全球包容性。例如,受访者强调需要投资快速机器翻译能力,以进行项目通信。领导者还讨论了在社区对话和决策中促进开源规范、遏制该行业的兄弟文化,并培养专业素养的重要性。

  7. 技术民族主义对开源合作构成严重威胁。 过去十年,美国和中国引入了越来越严格的措施,以限制关键创新技术的跨国转移。与此同时,俄罗斯和乌克兰之间的战争加剧了地缘政治紧张局势,并使技术供应链的安全成为政策必须。许多受访者引用证据表明,地缘政治紧张局势正在在全球创新社区中创造国家或地区的信息孤岛。许多开源领袖担心,日益保护主义的措施可能会限制开源代码的分发,并破坏社区对国际合作的无拘束态度。

  8. 透明的开源开发协议是技术民族主义的最佳解药。 为了对抗技术民族主义,开源社区必须缓解人们对于国家利益或恶意行为可能玷污或破坏开源项目的担忧。生态系统领袖认为,通过增强同行评审和第三方审计的声誉框架可以建立对软件开发过程的信任。受访者还呼吁开源基金会和项目定位为公正的参与者和协作的中立家园。他们认为,建立中立、包容和透明的合作结构不仅可以扩大参与范围,还可以减少生态系统参与者在国家或地区范围内创建并行努力的动机。

  9. 新开源项目的创立使得新基金会的数量相应增加。 一项实证研究发现,有100多个活跃的实体涵盖了广泛的开源项目。生态系统领袖表示,新基金会和新举措的不断增加正在导致日益增加的参与负担和供应商疲劳,一些企业更加谨慎地选择他们参与的方式和位置。然而,随着开源变得越来越全球化,许多生态系统领袖欢迎在世界各地创建新的开源组织。例如,利益相关者认识到,一些地区或行业基础的基金会可以更有效地满足其独特的成员需求。

  10. 生态系统领袖希望基金会在协调开源项目方面发挥更大的作用。 开源基金会不愿意在识别和支持优胜劣汰的开源项目方面发挥领导作用,他们认为选择胜者是市场功能。然而,领袖们认为需要更好的项目策划,希望基金会和其他生态系统参与者更加努力地将项目与相似的目标对齐。为此,基金会需要招募有经验和知识的熟练社区经理人,促使不同的利益相关者围绕共同目标形成对齐。领袖们还呼吁基金会将类似的项目纳入共享伞下,以消除重复,节省开支,并减少所谓的“供应商疲劳”。

  11. 保护和维护关键的开源基础设施应该是合作的重点。 所有生态系统领袖都认为,建立对开源软件的信任和信心,支持关键开源基础设施的持续维护是紧迫的任务。分散的创新正在产生一个非常广泛的开源组件网络,这些组件被广泛地部署以支持数字经济。然而,领袖们观察到,维护这些不同的组件是一个复杂的挑战,需要透明和协调的方法,以及来自开源基础设施的主要受益者的更大的资金和资源的投入。

  12. 需要增强的协作范围包括一系列互联网治理问题。 几位生态系统领袖认为,开源社区在技术政策对话中的影响力或主张力还不够强。他们认为缺乏一个协调的开源响应机制使得更大、更有资源的实体主导了这个领域。许多人希望共同努力推进开源在互联网治理问题上的倡导,包括网络安全、知识产权、隐私和反垄断等问题。生态系统领袖表示,在开源基金会之间加强政策问题的对齐,以及在公共部门设立开源办公室(OSPOs)以促进参与,将会有所帮助。



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.


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.2 As of October 2022, GitHub hosts 83 million developers, 4 million organizations, and over 200 million open source code repositories.3 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百万个代码库。2 截至2022年10月,GitHub托管了8300万开发者、400万组织和超过2亿个开源代码仓库。3 其中全球用户群体中有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?


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.4

表面上看,开源社区最近的记录似乎表明情况并非如此。毕竟,二十多年的开放合作已经产生了大量可重用的软件组件,并在数字经济中促进了无与伦比的创新和创造力。一项最近的估计(以及其他大多数估计)表明,现代应用程序栈的70%至90%由 OSS 组成,从操作系统到加密和网络功能再到运行全球公司的关键业务操作的企业应用程序。4

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?


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?


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?


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."5


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."6

Yoo 研究的内容主要是指开源开发项目中的复刻问题。他认为,当一个开源项目的贡献者将社区的源代码修改到不再能与项目的其他部分完全互通的程度时,就会出现最极端的分裂形式。最终的结果是将系统分为两个不同的、不兼容的版本。鉴于随之而来的经济效率低下,Yoo 总结为:"因此,对开源的灵活性的一些限制是不可避免的。"6

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 technologies7, Chinese users are the second most prolific group on GitHub after users from the United States.8

曾经在美国根深蒂固的开源社区,今天正变得越来越全球化和国际化。例如,中国已经成为开源技术的重要消费者和贡献者。不仅近90%的中国公司使用开源技术7,中国用户是 GitHub 上仅次于美国用户的第二大用户群体。8

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 players9. 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)对其国内软件产业的国际竞争力表示担忧,并将更深入地参与国际开源项目视为一种手段,使其与全球玩家处于平等地位9。 工信部正在投资一系列软件园区,实施额外的政策支持,并创建两三个开源基金会或社区,以增强中国的国际影响力。

"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. 10 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.11 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.12

中国技术领袖已经发起并支持了几个著名的开源项目。例如,阿里巴巴拥有中国最强大的开源人才库之一。作为 RISC-V(全球开源半导体制造商社区)的积极参与者,这家电子商务巨头最近采取了大胆的步骤,通过 OpenXuantie 项目对其半导体设计开发进行开源。10 在另一个例子中,百度于2017年推出了 Apollo,此后,Apollo 已发展成为全球领先的自动驾驶汽车开源解决方案之一。11 百度正在其 Apollo Go 机器人出租车服务中利用无人驾驶技术。自动驾驶出租车服务目前在中国五个城市运营,但该公司计划到2025年将 Apollo Go 扩展到65个城市,然后到2030年扩展到100个城市。12

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."13 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..."14

中国是开放源码软件全球化的一个突出例子。然而,许多新兴经济体包含大量开源开发者,包括印度、俄罗斯、韩国和乌克兰。哈佛商学院(Harvard Business School)的研究人员 Nataliya Langburd Wright、Frank Nagle和Shane Greenstein在最近的一项研究中观察到,“与发达经济体的同行一样,全球各地的程序员使用开源工具,使用开源词汇,并与开源库互动。”,13 正在催生新的创业企业,加快经济发展步伐。Wright、Nagle和Greenstein总结道,“OSS为中低收入国家提供了一个机会使其可以更快抵达技术前沿,相比从头开始开发此类软件或从昂贵的来源获得此类软件……” 14

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.


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."15 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 将技术民族主义定义为“将一个国家的技术能力和事业与国家安全、经济繁荣和社会稳定问题联系起来的重商主义行为”。15 这一新的技术民族主义标志着世界各国开始限制关键创新在国界之外的转移,相信这样做将刺激国家经济增长,并培育国内竞争优势。作为一个例子, 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."16

一些公共和私营部门领导人认为,无边界技术将超越这些民族主义倾向,并在未来几年推动互联互通,就像二十年前一样。例如,在世界经济论坛最近的一次会议上,IT服务公司 Wipro 的首席技术官 Jayraj Nair 认为,技术只会加速全球化。Nair 表示:“就技术而言,人工智能、5G或区块链的规模化,这些技术中的任何一项都将提高全球化的速度。”。“事实上,速度只会呈指数级增长。”16

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. 17 The net effect of these measures is a decoupling of strategic rivals from global supply chains, digital platforms, and knowledge networks.

其他观察人士则不那么乐观,他们预测,由于地缘政治紧张局势加剧,以及各国采取的保护主义措施增多,将进入一个新的去极端化时代。例如,2019年,北京命令其政府机构和公共机构停止使用外国制造的计算机和软件,以此打击美国科技公司。最近,华盛顿扩大了其出口管制条例所涵盖的先进技术的范围,将半导体制造商包括在内。除了阻止关键技术的流动,华盛顿还在全球范围内开展运动,阻止采用中国电信巨头华为开发的5G无线技术。17 这些措施的净效果是战略竞争对手与全球供应链、数字平台和知识网络脱钩。

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." 18 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 表示。“在代码审查中加入政治因素将损害这两者,并最终使中国的开源运动倒退。”18 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.19

墨卡托中国研究所(Mercator Institute for China Studies)的分析师 Rebecca Arcesati 也认为,Gitee和类似的中国土生土长的外资平台是中国政府更广泛努力的一部分,目的是减少该国对美国科技巨头的依赖,并使国内开源社区免受地缘政治紧张局势带来的风险。Arcesati 认为,大多数中国开发者不想与全球开源网络隔绝,对中国的发展方向持谨慎态度。Arcesati 表示:“北京方面越是试图将开源国有化,创建本土生态系统,开发商就越不愿意参与他们认为是政府主导的开源项目。”。19

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."20

Linux基金会的首席技术官 Chris Aniszczyk 指出,成熟的OSPO(开源办公室)越来越能帮助他们的组织应对项目政治并克服任何倾向于技术民族主义的倾向。Aniszczyk认为,OSPO可以帮助组织“理解和应对项目政治,例如在多个有影响力的参与者试图引导一个项目时保持中立立场,或揭示社区成员的潜在政治考虑。”他建议,“ OSPO 可以通过培养跨越国界和政治领域的个人和工作关系,帮助公司保持技术民族主义上的中立立场并弥合政治分歧。越来越多地,这个价值观延伸到基金会和非营利组织的工作,因为这些领域成为开源中重要的中立空间。”20

"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.


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.21 As Cánovas observes:

伴随着新开源项目的创建,新基金会的数量也有了相应的增加。加泰罗尼亚开放大学(the Universitat Oberta de Catalunya)的Javier Cánovas最近领导了一项关于开源基金会的实证研究,并在众多开源项目中发现了超过100个活跃的实体。21 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."


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."22

新基金会的激增已经导致一些企业在参与方式和领域上更加挑剔。例如,曾受雇于红帽公司的Deborah Bryant表示,她的 OSPO 正在耗费更多时间来定期重新评估公司对软件基金会的参与,以“确保(红帽)从投资中获得回报”。22

"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. 23

到如今,大多数OSS基金会都设在了加利福尼亚。然而,随着开源变得越来越全球化,许多生态系统领导者都承认,开源社区目前和未来的治理将不会仅仅局限于加州。Linux基金会的Jim Zemlin表示:“有时你需要特定的专业知识或能力来满足特定垂直领域或地区的需求。”“例如,欧盟正在致力于技术主权,并试图利用开源来削弱美国科技巨头的影响力。如果你在相关项目上希望获得欧盟的资助,那么就需要聘用欧洲专家,你的组织也必须在欧盟国家注册。”鉴于此,Linux基金会于2022年9月成立了欧洲分支机构(Linux基金会欧洲),以加强与欧洲资助者的合作关系,并为寻求在公共和私营部门利用开源解决方案的欧洲项目和公司提供一个窗口。23

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.


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."24 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."25

许多关键基础设施中都嵌入了分裂开源组件,这些基础设施为全球商业提供的基础服务从电网、物流和交通直到电子商务和金融。了解哪些组件使用最广泛、最容易被利用,对于开源生态系统和更广泛数字经济的持续健康至关重要。正如Linux基金会执行董事Jim Zemlin所阐述的,“在整个供应链中,有数十万个 OSS 软件包处于应用程序的研发中。明确了解哪些漏洞需要评估,是确保OSS长期安全和可持续发展的首要任务。”24 然而,正如哈佛大学创新科学实验室所持的态度,“很难完全了解开源软件的健康和安全程度,因为:(1)从设计上讲,开源软件本质上是分布式的,没有一个权威中枢对其质量和维护进行保证;(2)因为开源软件可以自由复制和修改,目前尚不清楚有多少开源软件,或者更确切地说,哪种类型的开源软件被广泛使用。”25

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."26 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所指出的一样,“在大多数情况下,没有官方的资源分配,很少有正式的规范或标准来保证关键开源代码的安全性。”26“尽管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.27 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希望大规模部署的情绪分析可以帮助研究人员识别可信的贡献者,以及需要加以警惕的个人和团体。27 然而事与愿违,开发人员和开源倡导者都认为任何政府监控都带有潜在的危害性和入侵性。这种项目可能会在政府计划支持的项目社区中引起反弹。

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.


In 2020, for example, more than 10% of Alphabet's full-time employ- ees (approximately 15,000) actively contributed to open source projects.28 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.28

例如,在2020年,超过10%的Alphabet全职员工(约15,000人)积极地为开源项目做出贡献。28 除了管理自己的开源代码库外,Alphabet的员工在大量的外部项目中做出了贡献,并积极参与提高开源及其供应链的安全性和可持续性。从亚马逊到VMware,数百家著名的企业和消费科技公司已经建立了 OSPO,并将相当比例的人力用于开发和维护开源项目,这是一个显著的进步现象。29

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."


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."


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 指出,数字公共服务、医疗保健、教育和气候变化是开源解决方案的重要机会领域。”“我们需要一个可重复和可信赖的过程,通过开源创新来实现公共政策目标。”



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."30

这种分散式创新和有效的领导力的结合对于开源项目的长期生存能力和成功至关重要。正如 Christopher Yoo 教授所说:“开源项目的成功取决于激发一群愿意为之工作的人的社区。从某种意义上说,开源领导者的权威性取决于追随者的存在。在所有贡献都是自愿的、社区始终可以通过分叉项目自由退出的世界中,领导者保留其职位的能力在很大程度上取决于他们对被领导者需求的反应性。这些需求包括提供快速反馈、作为技术争议和个性冲突的有效调解者、以及制定现实的中期和长期目标。” 30

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."31

正如 Yoo 教授所总结的:“说开源项目需要的领导方式与生产专有软件的商业公司的领导方式有所不同,并不意味着它们不需要领导。相反,确保开源平台不会分裂取决于一个具有足够权威来解决争端并将平台引导到有益方向的行动者的存在。”31

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.



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所说,“开源项目的扩散不一定是坏事,这只是意味着有很多选择。这也意味着我们需要更好的过滤器,以便开发人员和最终用户可以发现对他们有用的小模块。”


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。他非常注重社区。你需要找到那些具备生态系统领导技能的人。


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 说:“我们很擅长引入项目。但同样重要的是,我们要在适当的时候将项目引导通过生命周期,并对其进行归档。”


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.



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说。"你来自哪里,以及你为谁工作并不重要,知道你的工作是值得信任和高质量的才是重要的。所以我们需要针对代码库的声誉框架。"


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 说。"互联网是全球基础设施——必须保持中立。这对世界有利。"


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 基金会欧洲定义使命的座右铭:“本地合作,全球创新。”


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.32 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.33

无论用什么标准来衡量,开源软件系统都非常成功。数亿用户使用机顶盒、智能冰箱和其他家用电器使用 OSS,而数十亿人在访问Google、Facebook 或无数其他应用程序和网站时也在间接使用 OSS。无论你开特斯拉、丰田还是奔驰,它背后很有可能都在运行Linux和开源软件。32 超级计算机也是如此,它们为从先进气候模型到支持AI药物发现和其他科学研究(如天文学、气象学和核物理学)的一切提供动力。33

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 最近是美国国家研究委员会“未来环保科学委员会”的委员、多伦多大学蒙克全球事务学院的访问学者以及巴西自由教育项目的首席顾问。他的技术和创新工作曾在《哈佛商业评论》、《赫芬顿邮报》和《环球邮报》等出版物中受到关注。



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.



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 基金会研究正在为全球组织创建开源洞察的权威库。






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月。


  1. https://merics.org/en/short-analysis/china-bets-open- source-technologies-boost-domestic-innovation 2

  2. (https://nira.com/github-history/) 2

  3. (https://github.com/about) 2

  4. https://www.sonatype.com/hubfs/Corporate/Software%20Supply%20 Chain/2020/SON_SSSC-Report-2020_final_aug11.pdf?hsLang=en-us 2

  5. https://lisboncouncil.net/wp-content/uploads/2020/08/Open-Source- Modular-Platforms-and-the-Challenge-of-Fragmentatio-1-1.pdf 2

  6. https://lisboncouncil.net/wp-content/uploads/2020/08/Open-Source- Modular-Platforms-and-the-Challenge-of-Fragmentatio-1-1.pdf 2

  7. (https://interconnected.blog/open-source-in-china-the-players/) 2

  8. (https://octoverse.github.com/#the-world-of-open-source) 2

  9. (https://www.theregister.com/2021/12/01/china_five_year_software_plan/) 2

  10. https://riscv.org/news/2021/10/alibaba-announces-open- source-risc-v-based-xuantie-series-processors-pandaily/ 2

  11. (https://developer.apollo.auto/) 2

  12. https://www.cnbc.com/2021/11/18/chinas-baidu-wants-to- launch-robotaxi-service-in-100-cities-by-2030.html 2

  13. https://www.hbs.edu/ris/Publication%20Files/20-139_ f108f488-ae3a-45e1-a1c8-38d83dfa661b.pdf 2

  14. https://www.hbs.edu/ris/Publication%20Files/20-139_ f108f488-ae3a-45e1-a1c8-38d83dfa661b.pdf 2

  15. https://thediplomat.com/2020/09/us-china-techno- nationalism-and-the-decoupling-of-innovation/ 2

  16. https://www.weforum.org/agenda/2019/07/the-rise-of- techno-nationalism-and-the-paradox-at-its-core/ 2

  17. https://www.nytimes.com/2022/07/05/us/ politics/us-china-export-controls.html 2

  18. https://www.technologyreview.com/2022/05/30/1052879/ censoring-china-open-source-backfire/ 2

  19. https://merics.org/en/short-analysis/china-bets-open- source-technologies-boost-domestic-innovation 2

  20. https://linuxfoundation.org/wp-content/uploads/ LFResearch_OSPO_Report.pdf 2

  21. https://livablesoftware.com/study-open-source-foundations/ 2

  22. https://linuxfoundation.org/wp-content/uploads/ LFResearch_OSPO_Report.pdf 2

  23. https://www.linuxfoundation.org/press/press- release/linux-foundation-europe-launches 2

  24. https://www.hbs.edu/news/releases/Pages/census-open-source- software-security.aspx# 2

  25. https://www.coreinfrastructure.org/wp-content/uploads/ sites/6/2020/02/census_ii_vulnerabilities_in_the_core.pdf 2

  26. https://www.blog.google/technology/safety-security/making- open-source-software-safer-and-more-secure/ 2

  27. https://www.technologyreview.com/2022/07/14/1055894/ us-military-sofware-linux-kernel-open-source/ 2

  28. https://opensource.googleblog.com/2021/08/metrics-spikes-and- uncertainty-open-source-contribution-during-a-global-pandemic.html 2 3

  29. https://linuxfoundation.org/wp-content/uploads/ LFResearch_OSPO_Report.pdf

  30. https://lisboncouncil.net/wp-content/uploads/2020/08/Open-Source- Modular-Platforms-and-the-Challenge-of-Fragmentatio-1-1.pdf 2

  31. https://lisboncouncil.net/wp-content/uploads/2020/08/Open-Source- Modular-Platforms-and-the-Challenge-of-Fragmentatio-1-1.pdf 2

  32. https://www.automotivelinux.org/ 2

  33. https://www.zdnet.com/article/supercomputer-leaders- come-together-on-new-open-source-framework/ 2

· 阅读需 986 分钟


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).


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.


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/>.




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.


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.


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.


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的区别;

  • 开始了解有关软件的衍生和组合作品的复杂性的基础知识。


第一章 什么是软件自由?

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"1, 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.

许多人将具有这些自由的软件称为“开源”。除了与那些将此类软件称为“自由软件” 1 的人有着不同的政治关注点之外,将软件称为“开源”的人通常关注的是一个次要问题。具体来说,用户访问程序的源代码是实现修改自由的先决条件。然而,重要的问题是在适用于该源代码的许可证中授予了哪些自由。

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".


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.


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.


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.)


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. 2 Such noncommercial sharing is the primary reason that Free Software thrives.

如果没有分享改进的自由,修改和改进的自由多少有点空洞。软件自由社区建立在无私共享改进的自由软件的基础上。从历史上看,自由软件项目的典型做法是建立一个邮件列表,开发社区的成员可以在其中免费分享改进的内容。2 这种非商业性质的共享方式是自由软件蓬勃发展的主要原因。

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.3 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).4 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.

适用于软件的主要法律制度是版权法。专有软件的存在完全是因为版权法对软件的管理规定。3关于软件的版权法,主要是对软件的复制、修改和再发行的管理规定(有关美国的详细信息,请参阅《美国法典》第17篇§106§117)。4 根据法律(在美国和大多数其他司法管辖区),作品的版权持有者(通常是作者本人) 可以控制其他人如何复制、修改和/或分发作品。专有软件的这些控制行为禁止了软件的相关操作。此外,专有软件分销商只发行二进制可执行代码,严格保密源代码,这也进一步阻碍了实际意义上的代码修改。

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.5


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.


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.


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.


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'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.


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.


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 6. 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许可的“作品”或“基于作品的作品”都必须遵守其要求,包括所有相应的源代码 6。因此,copyleft许可证,特别是较强的许可证,旨在确保相同的许可证涵盖当地版权法认可的“基于作品的作品”的所有版本,从而确保实现与当前copyleft版权作品相关的所有用户、开发者、作者和读者的软件自由的特定战略目标。

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.7

  • 软件自由社区中的人做了很多努力,希望能终止通过读取软件内容生成专利的行为(即跟软件思想相关的专利),但还是未能成功。因此,一个软件程序可能看起来不受限制,但有些人可能会读取该软件并生成专利,进而毁掉其他用户的一切。7

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.8 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)通常对用户行使软件自由的能力施加技术限制。8最简单的(也是最古老的)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.


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 美国之外的版权制度

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.


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.


Simply put, though, the GPL ultimately creates a community of equality for both business and noncommercial users.


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.


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.


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.


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.


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.9 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最初是由两名研究生在业余时间开发的,并在学术环境中部署,并未商业化。9 之后很快商业公司就发现了该软件也适用于他们,公司的系统管理员开始使用它取代了微软的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.


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.


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.


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.



第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.


However, the GPL had both earlier versions before version 2, and, more well known, a revision to version


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.1

为了实现对完全兼容Unix的操作系统的应用、保证所有人的软件自由,Richard M. Stallman(RMS)于1984年创建“GUN Not Unix(GNU)”项目。然而,RMS发现使用许可证可以赋予却不能保证软件自由,这可能与GUN项目的目标背道而驰。于是RMS发明了“著佐权”来解决这个问题,并且开始在早期GNU项目程序中使用各种形式的著佐权许可证。1

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:


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:2


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.3 The GPLv1's innovation of reusable licensing infrastructure, an obvious fact today, was indeed a novel invention for its day.4


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).


While this tutorial does not discuss the terms of GPLv1 in detail, it is worth noting below the three key changes that GPLv2 brought:


  • 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.


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.5 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.


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.


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 and its terms are discussed in detail in Chapter [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.


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")6

  • 指定一个特定的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.


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.


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.


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.


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.



第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.


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:


"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.


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.


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]节。)


第四章 衍生作品:法规和案例法

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.


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.


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.


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:


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.


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.


4.2.1 Abstraction

4.2.1 抽象化

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.


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:


  • 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.


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.


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.


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.


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.


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.



第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.11


Next, we again encounter the same matter that appears in GPLv2 *§*0, in the following text:


"...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.


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:


[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.


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.


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 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.


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).


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,12 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却说他们可以。避免这种混淆: “免费”不是禁止重新发布者在执行受版权法约束的行为时收费,12 而是他们不能为软件本身收取单独的许可费用。换句话说,(修改和未修改的)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.


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.13

对于 GPLv2 的作品进行私有修改的问题需要特别注意。虽然 GPLv3 2 2 中明确列出了这些权利(有关详情请参见本教程的 9.4 部分),但是在 GPLv2 中,创造私有修改的许可大多是暗含的。特别是,GPLv2 2(和将在下一节讨论的 GPLv2 3)的要求围绕两个不同的版权控制展开:修改和分发。因此,只有在分发修改版本时才需要遵守 GPLv2 2 的要求;对于未分发的修改版本,不需要遵守这些要求。13

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"14) 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).


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.


Indeed, CCS needs completely include not just that source which is directly translated by the compiler into object code, but other materials necessary to convert the source into equivalent binaries. Specifically, GPLv2 3 requires that the source code include "meta-material" like scripts, interface definitions, and other material that is used to "control compilation and installation" of the binaries. In this manner, those further down the distribution chain are assured that they have the unabated freedom to build their own modified works from the sources provided.

事实上,CCS必须完全包括不仅直接由编译器转换为目标代码的源代码,还包括将源代码转换为等效二进制文件所需的其他材料。具体而言,GPLv2 3要求源代码包括“元材料”,如脚本、接口定义和其他用于“控制编译和安装”二进制文件的材料。以这种方式,分销链中的下游用户可以确保他们可以从提供的源代码构建自己的修改作品,而没有受到任何限制。

This requirement is not merely of theoretical value. If you pay a high price for a copy of GPL'd binaries (which comes with CCS, of course), you have the freedom to redistribute that work at any fee you choose, or not at all. Sometimes, companies attempt a GPL-violating cozenage whereby they produce very specialized binaries (perhaps for an obscure architecture). They then give source code that does correspond, but withhold the "incantations" and build plans they used to make that source compile into the specialized binaries. Such distributions violate GPL, since the downstream users cannot effectively "control compilation and installation" of the binaries.


5.2.2 Additional Source Provision Options

5.2.2 其他提供源代码的选项

Software distribution comes in many forms. Embedded manufacturers, for example, have the freedom to put GPL'd software into mobile devices with very tight memory and space constraints. In such cases, putting the source right alongside the binaries on the machine itself might not be an option. While it is recommended that this be the default way that people comply with GPL, the GPL does provide options when such distribution is unfeasible.


GPLv2 3, therefore, allows source code to be provided on any physical "medium customarily used for software interchange." By design, this phrase covers a broad spectrum --- the phrase seeks to pre-adapt to changes in technology. When GPLv2 was first published in June 1991, distribution on magnetic tape was still common, and CD was relatively new. By 2002, CD was the default. By 2007, DVD's were the default. Now, it's common to give software on USB drives and SD cards. This language in the license must adapt with changing technology.

因此,GPLv2 3允许在任何“用于软件交换的通常物理介质”上提供源代码。这个短语的设计旨在涵盖广泛的领域,它试图预先适应技术的变化。当GPLv2于1991年6月首次发布时,磁带分发仍然很常见,而CD则相对较新。到2002年,CD是默认选项。到2007年,DVD成为默认选项。现在,常见的做法是在USB驱动器和SD卡上提供软件。许可证中的这种语言必须随着技术的变化而适应。

Meanwhile, the binding created by the word "customarily" is key. Many incorrectly believe that dis- tributing binary on CD and source on the Internet is acceptable. In the corporate world in industrialized countries, it is indeed customary to simply download a CDs' worth of data quickly. However, even today in the USA, many computer users are not connected to the Internet, and most people connected to the Internet still have limited download speeds. Downloading CDs full of data is not customary for them in the least. In some cities in Africa, computers are becoming more common, but Internet connectivity is still available only at a few centralized locations. Thus, the "customs" here are normalized for a worldwide userbase. Simply providing source on the Internet --- while it is a kind, friendly and useful thing to do --- is not usually sufficient.


Note, however, a major exception to this rule, given by the last paragraph of GPLv2 3. If distribution of the binary files is made only on the Internet (i.e., "from a designated place"), then simply providing the source code right alongside the binaries in the same place is sufficient to comply with GPLv2 *§*3.

然而,GPLv2 3最后一段给出了一个主要例外。如果二进制文件的分发只是在互联网上进行(即“从指定的位置”),那么在同一位置直接提供源代码与二进制文件就足以符合GPLv2 §3的要求。

As is shown above, under GPLv2 3(a), embedded manufacturers can put the binaries on the device and ship the source code along on a CD. However, sometimes this turns out to be too costly. Including a CD with every device could prove too costly, and may practically (although not legally) prohibit using GPL'd software. For this situation and others like it, GPLv2*§* 3(b) is available.

如上所示,在GPLv2 3(a)下,嵌入式制造商可以将二进制文件放在设备上并将源代码放在CD上进行运输。然而,有时这种做法会被认为成本过高。为每个设备包含CD可能会过于昂贵,而且实际上可能(尽管法律上不允许)禁止使用GPL'd软件。对于这种情况和其他类似情况,GPLv2 § 3(b)是可用的。

GPLv2 3(b) allows a distributor of binaries to instead provide a written offer for source code alongside those binaries. This is useful in two specific ways. First, it may turn out that most users do not request the source, and thus the cost of producing the CDs is saved --- a financial and environmental windfall. In addition, along with a GPLv2 3(b) compliant offer for source, a binary distributor might choose to also give a URL for source code. Many who would otherwise need a CD with source might turn out to have those coveted high bandwidth connections, and are able to download the source instead --- again yielding environmental and financial windfalls.

GPLv2 3(b)允许二进制分发者提供书面源代码提供,而不是与这些二进制文件一起提供源代码。这有两个具体的用途。首先,可能大多数用户不请求源代码,因此节省了制作CD的成本 - 这是一笔财务和环境的收益。此外,与GPLv2 3(b)兼容的源代码提供书面提供,二进制分发者可能会选择为源代码也提供URL。许多其他需要源CD的人可能会发现拥有所需的高带宽连接,能够下载源代码,从而再次产生环境和财务收益。

However, note that regardless of how many users prefer to get the source online, GPLv2 3(b) does place lasting long-term obligations on the binary distributor. The binary distributor must be prepared to honor that offer for source for three years and ship it out (just as they would have had to do under GPLv2 3(a)) at a moment's notice when they receive such a request. There is real organizational cost here: support engineers must be trained how to route source requests, and source CD images for every release version for the last three years must be kept on hand to burn such CDs quickly. The requests might not even come from actual customers; the offer for source must be valid for "any third party".

但是,请注意,无论有多少用户喜欢在线获取源代码,GPLv2 3(b)都会对二进制分发者产生长期的持续义务。二进制分发者必须准备好在三年内执行源代码提供书面提供的义务,并在收到此类请求时立即运输(就像在GPLv2 3(a)下所必须做的那样)。这里确实存在实际的组织成本:支持工程师必须接受培训以了解如何路由源请求,并且必须保留过去三年每个发布版本的源CD映像以便快速刻录这些CD。这些请求甚至可能不是来自实际的客户;源代码提供书面提供必须对“任何第三方”有效。

That phrase is another place where some get confused --- thinking again that full public distribution of source is required. The offer for source must be valid for "any third party" because of the freedoms of redistribution granted by GPLv2 1--2. A company may ship a binary image and an offer for source to only one customer. However, under GPL, that customer has the right to redistribute that software to the world if she likes. When she does, that customer has an obligation to make sure that those who receive the software from her can exercise their freedoms under GPL --- including the freedom to modify, rebuild, and redistribute the source code.

这句话是另一个容易让人困惑的地方 —— 再次认为必须完全公开发布源代码。由于 GPLv2 1-2 授予的再分发自由,源代码的提供必须对“任何第三方”有效。一家公司可以向一个客户提供一个二进制映像和一个源代码的提供,但在 GPL 下,该客户有权将该软件重新分发给全世界,如果她愿意的话。当她这样做时,该客户有义务确保那些从她那里接收软件的人可以行使 GPL 下的自由权利,包括修改、重建和重新分发源代码。

GPLv2 3(c) is created to save her some trouble, because by itself GPLv2 3(b) would unfairly favor large companies. GPLv2 3(b) allows the separation of the binary software from the key tool that people can use to exercise their freedom. The GPL permits this separation because it is good for re-distributors, and those users who turn out not to need the source. However, to ensure equal rights for all software users, anyone along the distribution chain must have the right to get the source and exercise those freedoms that require it.

GPLv2 3(c) 的创建是为了节省她的一些麻烦,因为单独 GPLv2 3(b) 将不公平地偏向大公司。GPLv2 3(b) 允许将二进制软件与人们用于行使其自由的关键工具分离。GPL 允许这种分离,因为这对重新分发者和那些不需要源代码的用户是有益的。然而,为了确保所有软件用户的平等权利,沿着分发链的任何人都必须有权获取源代码并行使需要源代码的自由。

Meanwhile, GPLv2 3(b)'s compromise primarily benefits companies that distribute binary software commercially. Without GPLv2 3(c), that benefit would be at the detriment of the companies' customers; the burden of source code provision would be unfairly shifted to the companies' customers. A customer, who had received binaries with a GPLv2 3(b)-compliant offer, would be required under GPLv2 (sans GPLv2 3(c)) to acquire the source, merely to give a copy of the software to a friend who needed it. GPLv2 3(c) reshifts this burden to entity who benefits from GPLv2 3(b).

与此同时,GPLv2 3(b) 的妥协主要使得商业分发二进制软件的公司受益。如果没有 GPLv2 3(c),这种利益将损害公司的客户;源代码提供的负担将不公平地转移到公司的客户身上。一个已收到 GPLv2 3(b)-兼容提供的二进制文件的客户,将根据 GPLv2 (不带 GPLv2 3(c)) 要求获取源代码,仅仅是为了将软件副本提供给需要的朋友。GPLv2 3(c) 将这个负担重新转移到从 GPLv2 3(b) 受益的实体身上。

GPLv2 3(c) allows those who undertake noncommercial distribution to simply pass along a GPLv2 3(b)- compliant source code offer. The customer who wishes to give a copy to her friend can now do so without provisioning the source, as long as she gives that offer to her friend. By contrast, if she wanted to go into business for herself selling CDs of that software, she would have to acquire the source and either comply via GPLv2 3(a), or write her own GPLv2 3(b)-compliant source offer.

GPLv2 3(c) 允许那些进行“非商业”分发的人简单地传递一个 GPLv2 3(b) —— 兼容的源代码提供。希望将副本交给她朋友的客户现在可以这样做,而无需提供源代码,只要她把这个提供转交给她的朋友即可。相比之下,如果她想自己开业,销售该软件的 CD,她将不得不获取源代码,并通过 GPLv2 3(a) 或编写自己的 GPLv2 3(b) —— 兼容的源代码提供来遵守 GPL。

This process is precisely the reason why a GPLv2 3(b) source offer must be valid for all third parties. At the time the offer is made, there is no way of knowing who might end up noncommercially receiving a copy of the software. Companies who choose to comply via GPLv2 3(b) must thus be prepared to honor all incoming source code requests. For this and the many other additional necessary complications under GPLv2 *§§*3(b--c), it is only rarely a better option than complying via GPLv2 *§*3(a).

这个过程正是 GPLv2 3(b) 源代码提供必须对所有第三方有效的原因。在提供源代码的时候,没有办法知道谁会非商业地获得软件的副本。因此,选择通过 GPLv2 3(b) 来遵守许可证的公司必须准备好满足所有源代码请求。因为在 GPLv2 §3(b-c) 下有许多其他必要的复杂程序,所以这种方式通常不如遵守 GPLv2 §3(a)。


第6章 GPL的暗示专利授权

We digress again briefly from our section-by-section consideration of GPLv2 to consider the interaction between the terms of GPL and patent law. The GPLv2, despite being silent with respect to patents, actually confers on its licensees more rights to a licensor's patents than those licenses that purport to address the issue. This is the case because patent law, under the doctrine of implied license, gives to each distributee of a patented article a license from the distributor to practice any patent claims owned or held by the distributor that cover the distributed article. The implied license also extends to any patent claims owned or held by the distributor that cover "reasonably contemplated uses" of the patented article. To quote the Federal Circuit Court of Appeals, the highest court for patent cases other than the Supreme Court:


Generally, when a seller sells a product without restriction, it in effect promises the purchaser that in exchange for the price paid, it will not interfere with the purchaser's full enjoyment of the product purchased. The buyer has an implied license under any patents of the seller that dominate the product or any uses of the product to which the parties might reasonably contemplate the product will be put.


Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d 1445, 1451 (Fed. Cir. 1997).

Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc.,123 F.3d 1445, 1451(Fed. Cir. 1997)。

Of course, Free Software is licensed, not sold, and there are indeed restrictions placed on the licensee, but those differences are not likely to prevent the application of the implied license doctrine to Free Software, because software licensed under the GPL grants the licensee the right to make, use, and sell the software, each of which are exclusive rights of a patent holder. Therefore, although the GPLv2 does not expressly grant the licensee the right to do those things under any patents the licensor may have that cover the software or its reasonably contemplated uses, by licensing the software under the GPLv2, the distributor impliedly licenses those patents to the GPLv2 licensee with respect to the GPLv2'd software.


An interesting issue regarding this implied patent license of GPLv2'd software is what would be considered "uses of the [software] to which the parties might reasonably contemplate the product will be put." A clever advocate may argue that the implied license granted by GPLv2 is larger in scope than the express license in other Free Software licenses with express patent grants, in that the patent license clause of many of those other Free Software licenses are specifically limited to the patent claims covered by the code as licensed by the patentee.

关于 GPLv2 软件的这个暗示专利许可的一个有趣问题是,“当事方可能合理地预期产品将被用于的软件用途”。一个聪明的辩护人可能会主张,GPLv2 授予的暗示许可比其他明示专利授权的自由软件许可证的范围更广,因为许多其他自由软件许可证的专利许可条款特别限制了专利权人许可的代码所涵盖的专利权主张。

In contrast, a GPLv2 licensee, under the doctrine of implied patent license, is free to practice any patent claims held by the licensor that cover "reasonably contemplated uses" of the GPL'd code, which may very well include creation and distribution of modified works since the GPL's terms, under which the patented code is distributed, expressly permits such activity.

相比之下,GPLv2 授权人根据暗示专利许可原则可以自由实践授权人拥有的涵盖“合理预期用途”的专利权主张,这很可能包括创建和分发修改后的作品,因为 GPL 的条款明确允许这种活动,而该专利权主张覆盖了GPL的代码所涵盖的内容。

Further supporting this result is the Federal Circuit's pronouncement that the recipient of a patented article has, not only an implied license to make, use, and sell the article, but also an implied patent license to repair the article to enable it to function properly, Bottom Line Mgmt., Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the Federal Circuit extended that rule to include any future recipients of the patented article, not just the direct recipient from the distributor. This theory comports well with the idea of Free Software, whereby software is distributed among many entities within the community for the purpose of constant evolution and improvement. In this way, the law of implied patent license used by the GPLv2 ensures that the community mutually benefits from the licensing of patents to any single community member.

联邦巡回法院在 Bottom Line Mgmt.,Inc. v. Pan Man,Inc.,228 F.3d 1352(Fed. Cir. 2000)中进一步支持了这一结果,该法院宣称,专利物品的接收者不仅具有制造、使用和销售该物品的暗示许可,而且还具有修理该物品以使其正常运行的暗示专利许可,而这也适用于专利物品的任何未来接收者,而不仅仅是从分销商直接接收的接收者。这个理论与自由软件的思想相符,即将软件分发给社区中的许多实体,以实现不断的演进和改进。通过GPLv2使用的暗示专利许可法,确保社区从专利许可中共同受益。

Note that simply because GPLv2'd software has an implied patent license does not mean that any patents held by a distributor of GPLv2'd code become worthless. To the contrary, the patents are still valid and enforceable against either:

需要注意的是,仅因为 GPLv2 的软件具有暗示专利许可,并不意味着任何分发 GPLv2 软件的公司持有的专利就变得毫无价值。相反,这些专利仍然有效,并且可以针对以下任一方强制执行:

a. any software other than that licensed under the GPLv2 by the patent holder, and

b. any party that does not comply with the GPLv2 with respect to the licensed software.

a. 除了由专利持有人授权的GPLv2软件之外的任何软件;

b. 与许可软件有关的任何方不遵守GPLv2许可证。

For example, if Company has a patent on advanced Web browsing, but also licenses a Web browsing program under the GPLv2, then it cannot assert the patent against any party based on that party's use of Company 's GPL'd Web browsing software program, or on that party's creation and use of modified versions of that GPL'd program. However, if a party uses that program without complying with the GPLv2, then Company can assert both copyright infringement claims against the non-GPLv2-compliant party and infringement of the patent, because the implied patent license only extends to use of the software in accordance with the GPLv2. Further, if Company distributes a competitive advanced Web browsing program that is not a modified version of Company 's GPL'd Web browsing software program, Company is free to assert its patent against any user or distributor of that product. It is irrelevant whether Company 's program is also distributed under the GPLv2, as Company can not grant implied licenses to Company 's patent.

例如,如果一家公司拥有先进的Web浏览专利,但也根据GPLv2许可证授权了一个Web浏览程序,那么它就不能基于该方使用公司的GPLv2 Web浏览软件程序或者使用该程序的修改版本来主张专利权。然而,如果一方未遵守GPLv2使用了该程序,那么公司可以主张针对该非GPLv2兼容方的版权侵权索赔和专利侵权,因为暗示的专利许可仅限于按照GPLv2使用软件。此外,如果公司发布一款不是公司的GPLv2 Web浏览软件程序的改进版竞争性先进Web浏览程序,那么公司可以自由地针对该产品的任何用户或分销商主张其专利权。无论公司的程序是否也在GPLv2下发布,都是无关紧要的,因为公司不能授予对公司的专利的暗示许可证。

This result also reassures companies that they need not fear losing their proprietary value in patents to competitors through the GPLv2 implied patent license, as only those competitors who adopt and comply with the GPLv2's terms can benefit from the implied patent license. To continue the example above, Company does not receive a free ride on Company 's patent, as Company has not licensed-in and then redistributed Company A's advanced Web browser under the GPLv2. If Company does do that, however, Company still has not lost competitive advantage against Company , as Company must then, when it re-distributes Company 's program, grant an implied license to any of its patents that cover the program. Further, if Company relicenses an improved version of Company A's program, it must do so under the GPLv2, meaning that any patents it holds that cover the improved version are impliedly licensed to any licensee. As such, the only way Company can benefit from Company 's implied patent license, is if it, itself, distributes Company 's software program and grants an implied patent license to any of its patents that cover that program.



第7章 在多个方面捍卫自由

Chapters [3] and [5] presented the core freedom-defending provisions of GPLv2, which are in GPLv2 0--3. GPLv2 4--7 of the GPLv2 are designed to ensure that GPLv2 0--3 are not infringed, are enforceable, are kept to the confines of copyright law but also not trumped by other copyright agreements or components of other entirely separate legal systems. In short, while GPLv2 *§§*0--3 are the parts of the license that defend the freedoms of users and programmers, GPLv2 *§§*4--7 are the parts of the license that keep the playing field clear so that §§ 0--3 can do their jobs.

第3章和第5章介绍了 GPLv2 的核心捍卫自由条款,即 GPLv2 第0-3条。GPLv2 的 第4-7条旨在确保 GPLv2 第0-3条不被侵犯、可执行,并受到版权法的限制,但也不会被其他版权协议或完全独立的法律体系的组成部分所取代。简而言之,虽然 GPLv2 第0-3条是捍卫用户和程序员自由的许可证部分,但 GPLv2 第4-7条是保持竞争环境清晰的许可证部分,以便第0-3条可以发挥其作用。

7.1 GPLv2 §4: Termination on Violation

7.1 GPLv2 第4条:违规终止

GPLv2 4 is GPLv2's termination clause. Upon first examination, it seems strange that a license with the goal of defending users' and programmers' freedoms for perpetuity in an irrevocable way would have such a clause. However, upon further examination, the difference between irrevocability and this termination clause becomes clear. (See 7.4 for expanded discussion of GPLv2 irrevocability.)

GPLv2 4 是 GPLv2 的终止条款。初看起来,一个旨在永久且不可撤销地捍卫用户和程序员自由的许可证竟然有这样的条款,似乎有些奇怪。然而,进一步的研究表明,不可撤销和此终止条款之间的区别变得清晰了。(有关 GPLv2 不可撤销的更广泛讨论,请参见7.4。)

The GPL is irrevocable in the sense that once a copyright holder grants rights for someone to copy, modify and redistribute the software under terms of the GPL, they cannot later revoke that grant. Since the GPL has no provision allowing the copyright holder to take such a prerogative, the license is granted as long as the copyright remains in effect.15 The copyright holders have the right to relicense the same work under different licenses (see Section [12.2] of this tutorial), or to stop distributing the GPLv2'd version (assuming GPLv2 3(b) was never used), but they may not revoke the rights under GPLv2 already granted.

GPL是不可撤销的,因为一旦版权持有人授予他人在GPL条款下复制、修改和重新分发软件的权利,他们就不能撤回该授权。由于GPL没有允许版权持有人采取这种特权的规定,因此只要版权仍然有效,许可证就会被授予。15 版权持有人有权在不同的许可证下重新许可同一作品(请参见本教程的第12.2节),或停止分发GPLv2版本(假设从未使用GPLv2 3(b)),但他们不能撤销已授予的GPLv2下的权利。

In fact, when an entity loses their right to copy, modify and distribute GPL'd software, it is because of their own actions, not that of the copyright holder. The copyright holder does not decide when GPLv2 4 termination occurs (if ever); rather, the actions of the licensee determine that.

实际上,当一个实体失去复制、修改和分发GPL软件的权利时,是因为他们自己的行为,而不是版权持有人的行为。版权持有人不决定GPLv2 4终止的时间(如果有的话),而是许可证持有人的行为决定。

Under copyright law, the GPL has granted various rights and freedoms to the licensee to perform specific types of copying, modification, and redistribution. By default, all other types of copying, modification, and redistribution are prohibited. GPLv2 4 says that if you undertake any of those other types (e.g., redistributing binary-only in violation of GPLv2 3), then all rights under the license --- even those otherwise permitted for those who have not violated --- terminate automatically.

根据版权法,GPL已经授予许可证持有人执行特定类型的复制、修改和重新分发的各种权利和自由。默认情况下,所有其他类型的复制、修改和重新分发都是禁止的。GPLv2 4规定,如果您进行任何这些其他类型的活动(例如,在违反GPLv2 3的情况下重新分发仅限二进制文件),那么所有许可证下的权利,即使是对于没有违反许可证的人,也会自动终止。

GPLv2 4 makes GPLv2 enforceable. If licensees fail to adhere to the license, then they are stuck without any permission under to engage in activities covered by copyright law. They must completely cease and desist from all copying, modification and distribution of the GPL'd software.

GPLv2 4使GPLv2可强制执行。如果许可证持有人未能遵守许可证,那么他们就没有任何在版权法下从事活动的许可。他们必须完全停止所有对GPL软件的复制、修改和分发。

At that point, violating licensees must gain the forgiveness of the copyright holders to have their rights restored. Alternatively, the violators could negotiate another agreement, separate from GPL, with the copyright holder. Both are common practice, although Chapter [13.3] explains further key differences between these two very different uses of GPL.


7.2 GPLv2 第5条:接受、版权风格

GPLv2 5 brings us to perhaps the most fundamental misconception and common confusion about GPLv2. Because of the prevalence of proprietary software, most users, programmers, and lawyers alike tend to be more familiar with EULAs. EULAs are believed by their authors to be contracts, requiring formal agreement between the licensee and the software distributor to be valid. This has led to mechanisms like "shrink-wrap" and "click-wrap" as mechanisms to perform acceptance ceremonies with EULAs.

GPLv2 5 可能是关于 GPLv2 最基本的误解和常见混淆。由于专有软件的普及,大多数用户、程序员和律师都更熟悉使用许可协议(EULA)。 EULA 的作者认为它们是合同,需要许可人和软件分发商之间的正式协议才能有效。这导致了"缩小包装"和"点击包装"等机制来执行 EULA 的接受仪式。

The GPL does not need contract law to "transfer rights." Usually, no rights are transferred between parties. By contrast, the GPL is primarily a permission slip to undertake activities that would otherwise have been prohibited by copyright law. As such, GPL needs no acceptance ceremony; the licensee is not even required to accept the license.

GPLv2 5 可能是关于 GPLv2 最基本的误解和常见混淆。由于专有软件的普及,大多数用户、程序员和律师都更熟悉使用许可协议(EULA)。 EULA 的作者认为它们是合同,需要许可人和软件分发商之间的正式协议才能有效。这导致了"缩小包装"和"点击包装"等机制来执行 EULA 的接受仪式。

However, without the GPL, the activities of copying, modifying and distributing the software would have otherwise been prohibited. So, the GPL says that you only accepted the license by undertaking activities that you would have otherwise been prohibited without your license under GPL. This is a certainly subtle point, and requires a mindset quite different from the contractual approach taken by EULA authors.

然而,如果没有 GPL,复制、修改和分发软件的活动本来是被禁止的。因此,GPL 表示,只有在进行原本在没有 GPL 许可下被禁止的活动时,你才接受了许可证。这是一个非常微妙的点,需要一种与 EULA 作者采取的合同方法截然不同的思维方式。

An interesting side benefit to GPLv2 5 is that the bulk of users of Free Software are not required to accept the license. Undertaking fair and unregulated use of the work, for example, does not bind you to the GPL, since you are not engaging in activity that is otherwise controlled by copyright law. Only when you engage in those activities that might have an impact on the freedom of others does license acceptance occur, and the terms begin to bind you to fair and equitable sharing of the software. In other words, the GPL only kicks in when it needs to for the sake of freedom.

GPLv2 5 的一个有趣的附带好处是,大部分自由软件的用户不需要接受许可证。例如,进行公正和不受限制的作品使用不会约束您使用 GPL,因为您并没有从事受版权法控制的活动。只有当您从事可能会影响他人自由的活动时,许可证才会生效,并开始将您与软件的公平和公正共享的条款绑定在一起。换句话说,GPL 只会在需要自由的情况下启动。

While GPL is by default a copyright license, it is certainly still possible to consider GPL as a contract as well. For example, some distributors chose to "wrap" their software in an acceptance ceremony to the GPL, and nothing in the GPL prohibits that use. Furthermore, the ruling in Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008) indicates that both copyright and contractual remedies may be sought by a copyright holder seeking to enforce a license designed to uphold software freedom.

虽然 GPL 默认是一个版权许可证,但当然仍然可以将 GPL 视为合同。例如,一些发行商选择在 GPL 接受仪式中"包装"他们的软件,而 GPL 中没有禁止这种用法。此外,在 Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008) 的裁决中表明,寻求执行旨在维护软件自由的许可证的版权持有人可以同时寻求版权和合同救济措施。

7.3 GPLv2 §6: GPL, My One and Only

7.3 GPLv2 第6条: GPL,唯一的版权许可证

A point that was glossed over in Section 7.1's discussion of GPLv2 4 was the irrevocable nature of the GPL. The GPLv2 is indeed irrevocable, and it is made so formally by GPLv2 6.

在第7.1节讨论GPLv2 4时忽略了一个重要的问题,那就是GPLv2的不可撤销性。GPLv2确实是不可撤销的,GPLv2 6正式规定了这一点。

The first sentence in GPLv2 6 ensures that as software propagates down the distribution chain, that each licensor can pass along the license to each new licensee. Under GPLv2 6, the act of distributing automatically grants a license from the original licensor to the next recipient. This creates a chain of grants that ensure that everyone in the distribution has rights under the GPLv2. In a mathematical sense, this bounds the bottom --- making sure that future licensees get no fewer rights than the licensee before.

GPLv2 6的第一句确保了在软件沿着分发链传播时,每个许可人都可以将许可证传递给每个新的许可人。根据GPLv2 6,分发的行为自动授予原始许可人到下一个收件人的许可证。这创造了一系列的许可授权,确保分发中的每个人都在GPLv2下享有权利。从数学上讲,这将底部限制在一定范围内,确保未来的许可人得到的权利不少于前一个许可人。

The second sentence of GPLv2 6 does the opposite; it bounds from the top. It prohibits any licensor along the distribution chain from placing additional restrictions on the user. In other words, no additional requirements may trump the rights and freedoms given by GPLv2.

GPLv2 6的第二句则相反,它从顶部限制。它禁止沿着分发链的任何许可人对用户施加额外的限制。换句话说,没有额外的要求可以凌驾于GPLv2所赋予的权利和自由之上。

The final sentence of GPLv2 6 makes it abundantly clear that no individual entity in the distribution chain is responsible for the compliance of any other. This is particularly important for noncommercial users who have passed along a source offer under GPLv2 3(c), as they cannot be assured that the issuer of the offer will honor their GPLv2 3 obligations.

GPLv2 6的最后一句明确表示,在分发链中,没有任何个人实体对其他人的合规性负责。这对于已根据GPLv2 3(c)传递源代码的非商业用户尤其重要,因为他们无法确保发出源代码的人会履行他们GPLv2 3的义务。

In short, GPLv2 6 says that your license for the software is your one and only copyright license allowing you to copy, modify and distribute the software.

简而言之,GPLv2 6表示,该软件的许可证是您唯一的版权许可证,允许您复制、修改和分发该软件。

GPLv2 §6 is GPLv2's "automatic down stream licensing" provision16. Each time you redistribute a GPL'd program, the recipient automatically receives a license from each original licensor to copy, distribute or mod- ify the program subject to the conditions of the license. The redistributor need not take any to ensure the downstream recipient's acceptance of the license terms. This places every copyright holder in the chain of descent of the code in legal privity, or direct relationship, with every downstream redistributor. Two legal effects follow. First, downstream parties who remain in compliance have valid permissions for all actions (including modification and redistribution) even if their immediate upstream supplier of the software has been terminated for license violation17. Downstream's licensed rights are not dependent on compliance of their upstream, because their licenses issue directly from the copyright holder. Second, automatic termi- nation cannot be cured by obtaining additional copies from an alternate supplier: the license permissions emanate only from the original licensors, and if they have automatically terminated permission, no act by any intermediate license holder can restore those terminated rights18.

GPLv2 §6是GPLv2的“自动下游许可证”条款16。每次您重新分发GPL授权的程序,接收方都会自动从每个原始许可证人那里获得许可证,以复制、分发或修改程序,但须遵守许可证的条件。再分发者无需采取任何措施来确保下游接收方接受许可证条款。这将每个代码下降链中的版权持有人置于法律特权或直接关系中,与每个下游再分发者有关。随之而来的是两个法律效果。首先,保持合规的下游方对于所有行为(包括修改和再分发),即使他们的软件直接上游供应商已因许可证违规而被终止,也具有有效的权限17。下游方的许可权不依赖于上游的合规性,因为他们的许可证直接来自版权持有人。其次,自动终止无法通过从备用供应商获取其他副本来解决:许可证权限仅来自原始许可证人,如果他们已自动终止许可证,则任何中间许可证持有人的行为都无法恢复已终止的权利18

7.4 GPLv2 Irrevocability

7.4 GPLv2的不可撤销性

This section digresses briefly to examine the manner in which GPLv2 4--6 interact together to assure that the license grant is irrevocable. There are two legal theories why a contributor cannot terminate their license grant. First is an argument that the text of the GPL prevents it; second is that a contributor would be estopped from succeeding on an infringement claim for continued use of the code even if it wasn't removed.

这个章节简要地讨论了GPLv2 4-6是如何相互作用以确保许可证授权是不可撤销的。有两种法律理论可以解释为什么贡献者不能终止他们的许可证授权。第一个是GPL的文本阻止了它的发生,第二个是即使代码没有被删除,贡献者也无法成功地主张侵权。

7.4.1 The text of the GPLv2

7.4.1 GPLv2的文本

The GPLv2 have several provisions that, when taken together, can be construed as an irrevocable license from each contributor. First, the GPLv2 says "by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it" (GPLv2 5, emphasis added). A contributor by definition is modifying the code and therefore has agreed to all the terms in the GPLv2, which includes the web of mechanisms in the GPLv2 that ensure the code can be used by all.

GPLv2有几个规定,当它们放在一起时,可以被解释为每个贡献者提供了一个不可撤销的许可证。首先,GPLv2说,“通过修改或分发程序(或任何基于程序的工作),您表明接受本许可证以进行此类操作,以及为复制,分发或修改程序或基于它的工作的所有条款和条件”(GPLv2 5,重点强调)。按照定义,贡献者正在修改代码,因此同意了GPLv2中的所有条款,包括GPLv2中保证代码可以被所有人使用的机制。

More specifically, the downstream license grant says "the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (GPLv2 6). So in this step, the contributor has granted a license to the downstream, on the condition that the downstream complies with the license terms.

更具体地说,下游许可证授权说,“接收者自动从原始许可人那里获得许可证,以便根据这些条款和条件复制,分发或修改程序。”(GPLv2 6)。因此,在这一步中,贡献者已经授予了下游许可证,条件是下游用户遵守许可证条款。

That license granted to downstream is irrevocable, again provided that the downstream user complies with the license terms: "[P]arties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance" (GPLv2 4).

只要下游用户遵守许可证条款,向下游授予的许可证是不可撤销的:“只要这样的各方保持完全符合要求,从您处接收副本或权利的各方不会使其许可证终止”(GPLv2 4)。

Thus, anyone downstream of the contributor (which is anyone using the contributor's code), has an irrevocable license from the contributor. A contributor may claim to revoke their grant, and subsequently sue for copyright infringement, but a court would likely find the revocation was ineffective and the downstream user had a valid license defense to a claim of infringement.


Nevertheless, for purposes of argument, we will assume that for some reason the GPLv2 is not enforceable against the contributor19, or that the irrevocable license can be revoked20. In that case, the application of promissory estoppel will likely mean that the contributor still cannot enforce their copyright against downstream users.

尽管如此,为了论证的目的,我们将假设某种原因导致 GPLv2 对贡献者不可执行19,或者可撤销的不可撤销许可证20。在这种情况下,承诺诱导可能意味着贡献者仍然无法对下游用户执行其版权。

7.4.2 Promissory estoppel

7.4.2 承诺阻止

"Promissory estoppel" is a legal theory that says, under some circumstances, a promise is enforceable against the promisee even after the promisee tries to renege on the promise. The test for how and when promissory estoppel applies differs from state to state, but generally where there is a "promise which the promisor should reasonably expect to induce action or forbearance on the part of the promisee or a third person and which does induce such action or forbearance is binding if injustice can be avoided only by enforcement of the promise."21 Breaking it down, it is:

“承诺阻止”是一种法律理论,根据某些情况,即使承诺人试图食言,承诺也可以对承诺人生效。如何和何时应用承诺阻止的测试因州而异,但通常情况下,如果有“承诺能够合理预期促使承诺人或第三方采取行动或放弃采取行动的承诺,并且该承诺确实促使了这种行动或放弃采取行动,如果只有通过执行该承诺才能避免不公正,那么该承诺是具有约束力的。”21 将其分解为以下几点:

  1. where there is a clear and definite promise;

  2. where the promisor has a reasonable expectation that the offer will induce action or forbearance on the part of the promisee;

  3. which does induce actual and reasonable action or forbearance by the promisee; and

  4. which causes a detriment which can only be avoided by the enforcement of the promise.

  5. 存在明确和明确的承诺;

  6. 承诺人有合理的期望,即提供将促使承诺人采取行动或放弃采取行动;

  7. 确实促使承诺人采取了实际和合理的行动或放弃采取行动;以及

  8. 引起只有通过执行承诺才能避免的不利影响。

In this case, the promisor is the contributor. This should be an easy standard to meet in any widely used software.


  1. The promise is contained in the GPL, which is a promise that one can continue to use the licensed software as long as the terms of the license are met.

  2. A contributor knows that there is a broad user base and users consume the software relying on the grant in the GPL as assuring their continued ability to use the software (one might even say it is the sine qua non of the intent of the GPL).

  3. Users do, in fact, rely on the promises in the GPL, as they ingest the software and base their businesses on their continued ability to use the software.

  4. Whether the user will suffer detriment is case-specific, but using Linux, a software program that is often fundamental to the operation of a business, as an example, the loss of its use would have a significantly detrimental, perhaps even fatal, effect on the continued operation of the business.

  5. 承诺包含在GPL中,它承诺只要符合许可证条款,就可以继续使用许可的软件。

  6. 贡献者知道有广泛的用户群,用户使用许可证中的授权来保证他们继续使用软件(可以说这是GPL意图的不可或缺的组成部分)。

  7. 用户确实依赖GPL中的承诺,因为他们使用该软件,并基于其继续使用该软件来进行业务。

  8. 用户是否会遭受损失是具体情况而定,但以Linux为例,这是一种通常对企业运作至关重要的软件程序,其使用的丧失将对企业的持续运营产生显着的,甚至是致命的影响。

7.4.3 Conclusion

7.4.3 结论

Whether as a matter of a straightforward contractual obligation, or as a matter of promissory estoppel, a contributor's attempt to revoke a copyright license grant and then enforce their copyright against a user is highly unlikely to succeed.


7.5 GPLv2 §7: "Give Software Liberty or Give It Death!"

7.5 GPLv2 第7条:“给软件自由或给它死亡!”

In essence, GPLv2 7 is a verbosely worded way of saying for non-copyright systems what GPLv2 6 says for copyright. If there exists any reason that a distributor knows of that would prohibit later licensees from exercising their full rights under GPL, then distribution is prohibited.

实质上,GPLv2 7是一种措辞繁琐的表述方式,用于针对非版权系统,表达GPLv2 6对版权所说的意思。如果存在任何一个分发者知道会禁止后续许可人行使其在GPL下的全部权利的原因,那么就禁止分发。

Originally, this was designed as the title of this section suggests --- as a last ditch effort to make sure that freedom was upheld. However, in modern times, it has come to give much more. Now that the body of GPL'd software is so large, patent holders who would want to be distributors of GPL'd software have a tough choice. They must choose between avoiding distribution of GPL'd software that exercises the teachings of their patents, or grant a royalty-free, irrevocable, non-exclusive license to those patents. Many companies have chosen the latter.


Wathen Distillery Co., 10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937). The term nevertheless can be a term of indefinite length where its continuing effect is tied to the conduct of the parties. Id.

Wathen Distillery Co.,10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937)。然而,这个术语可以是一个无限期限的术语,其持续影响与各方的行为有关。Id。

Thus, GPLv2 7 rarely gives software death by stopping its distribution. Instead, it is inspiring patent holders to share their patents in the same freedom-defending way that they share their copyrighted works.

因此,GPLv2 7很少会通过停止软件分发来导致软件的死亡。相反,它鼓励专利持有人以维护自由的方式分享他们的专利,就像他们分享版权作品一样。

7.6 GPLv2 §8: Excluding Problematic Jurisdictions

7.6 GPLv2 第8条: 排除问题管辖区

GPLv2 8 is rarely used by copyright holders. Its intention is that if a particular country, say Unfreedonia, grants particular patents or allows copyrighted interfaces (no country to our knowledge even permits those yet), that the GPLv2'd software can continue in free and unabated distribution in the countries where such controls do not exist.

GPLv2 8很少被版权持有人使用。它的意图是,如果某个国家,比如Unfreedonia,授予特定的专利或允许版权接口(目前没有任何国家允许这些),那么GPLv2软件可以在这些管辖区不存在这些控制的国家中自由、无障碍地分发。

As far as is currently known, GPLv2 8 has very rarely been formally used by copyright holders. Ad- mittedly, some have used GPLv2 8 to explain various odd special topics of distribution (usually related in some way to GPLv2 7). However, generally speaking, this section is not proven particularly useful in the more than two decades of GPLv2 history.

据目前所知,GPLv2 8很少被版权持有人正式使用。诚然,有些人使用GPLv2 8来解释分发的各种奇怪特殊话题(通常与GPLv2 7有关)。然而,一般来说,这个部分在GPLv2的二十多年历史中并没有被证明特别有用。

Meanwhile, despite many calls by the FSF (and others) for those licensors who explicitly use this section to come forward and explain their reasoning, no one ever did. Furthermore, research conducted during the GPLv3 drafting process found exactly one licensor who had invoked this section to add an explicit geographical distribution limitation, and the reasoning for that one invocation was not fitting with FSF's intended spirit of GPLv2 *§*8. As such, GPLv2 *§*8 was not included at all in GPLv3.

与此同时,尽管自由软件基金会(FSF)和其他人多次呼吁那些明确使用此部分的许可方来说明他们的理由,但没有人这样做。此外,在GPLv3起草过程中进行的研究发现,只有一个许可方曾引用此部分以添加明确的地理分布限制,而该引用的理由与FSF旨在实现的GPLv2 §8的精神不符。因此,GPLv2 §8在GPLv3中根本没有被包含进来。


第8章 杂项,保证和绝对无保证

GPLv2 0--7 constitute the freedom-defending terms of the GPLv2. The remainder of the GPLv2 handles administrivia and issues concerning warranties and liability.

GPLv2 0-7条款构成GPLv2的捍卫自由条款。GPLv2的其余部分处理行政事务和与保证和责任有关的问题。

8.1 GPLv2 §9: FSF as Stewards of GPL

8.1 GPLv2 第9条: FSF作为GPL的监管者

FSF reserves the exclusive right to publish future versions of the GPL; GPLv2 9 expresses this. While the stewardship of the copyrights on the body of GPL'd software around the world is shared among thousands of individuals and organizations, the license itself needs a single steward. Forking of the code is often regrettable but basically innocuous. Forking of licensing is disastrous.

FSF保留了发布GPL未来版本的独有权利; GPLv2 9表达了这一点。虽然全球GPL软件版权的管理权由数千个个人和组织共同分享,但许可证本身需要一个唯一的管理者。代码的分叉通常是令人遗憾但基本无害的。许可证的分叉是灾难性的。

(Chapter [2] discusses more about the various versions of GPL.)


8.2 GPLv2 §10: Relicensing Permitted

8.2 GPLv2 第10条: 允许重新许可