diff --git a/sources/OSPO-101/module2/README.md b/sources/OSPO-101/module2/README.md index 47ed62b..9b15d9c 100644 --- a/sources/OSPO-101/module2/README.md +++ b/sources/OSPO-101/module2/README.md @@ -1,557 +1,491 @@ --- -status: collected +status: translated title: "OSPO 101 Training Modules - Module 2" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md --- -# Section: Introducing Open Source Business Models +# 1. 介绍 -## Lesson: Introduction +## 1.1 课程：简介 -### Section Overview +在本节中，我们将提供几个重要的开源商业模式的定义，以及它们之间的比较。 我们还将讨论每种方法的相对优势和劣势，并重点介绍哪些模型可以用于哪些业务场景。 -In this section, we will provide definitions of several important open source business models, as well as comparisons between them. We will also discuss the relative strengths and weaknesses of each approach, and highlight which models can be used in which business scenarios. +## 1.2 学习目标 -### Learning Objectives +在本节结束时，您应该能够： -By the end of this section, you should be able to: +- 定义最常用的开源商业模式。 +- 解释这些商业模式之间的异同。 +- 了解哪些模型最适合哪些业务场景。 -- Define the most often used open source business models. +## 2. 课程：定义 -- Explain the differences and similarities among these business models. +### 2.1 主要的开源商业模式有哪些？ -- Understand which models work best with which business scenarios. +有两种方法可以划分开源商业模式的概念——那些使用开源（大多数组织）的公司，以及那些主要生产开源的公司。 先说消费端。 -## Lesson: Definitions +#### 消费 -### What are the Major Open Source Business Models? +![Image description](strategic-use.png) -There are two ways to slice the notion of open source business models - those companies who consume open source (most organizations), vs. those who primarily produce open source. Let’s tackle the consumption side first. +上文重点介绍的 Gartner 最近的一项研究表明，一流的软件和技术组织使用其产品中大约 80% 的软件来自开源，然后在该软件堆栈之上构建其余 20% 的附加值为他们的客户提供产品。这样做可以让他们将有限的工程资源集中在差异化价值上，同时与开源生态系统的其余部分分担通用代码的开发成本。 -**Consumption** +那些生产开源代码的公司通常分为以下类型的商业模式（尽管他们也可能战略性地使用开源）： -![Moving to Strategic use of Open Source](strategic-use.png) +#### 许可 -A recent Gartner study, highlighted above, showed that best in class software and technology organizations consume roughly 80% of the software they use in their products from open source, and then build the remaining 20% of their value add on top of that software stack to provide products to their customers. Doing this allows them to focus limited engineering resources on differentiated value while sharing the development costs of common code with the rest of the open source ecosystem. +这种模式依赖于商业许可和开源许可下的双重许可软件，通常会产生产品的“社区版”和“企业版”，客户可以根据他们可能需要的功能进行选择产品。一个例子是 Oracle MySQL 数据库，它在商业许可证和 GNU 公共许可证下获得许可（后面的模块将更详细地介绍许可证）。 -Those companies producing open source code generally fall into the following types of business models (though they also likely strategically consume open source as well): +#### 托管 -**Licensing** +在此模型中，公司在云托管的 SaaS（软件即服务模型）中提供开源产品。这方面的主要例子是亚马逊（亚马逊网络服务）和谷歌（谷歌云）等公司，它们以强化的、可扩展的、企业级配置托管开源技术。 -This model relies on dual-licensing software under both a commercial license as well as an open source license, usually resulting in a ‘community edition’ and an ‘enterprise edition’ of the product that customers can choose depending upon what features they may need in the product. An example is the Oracle MySQL database, licensed under both a commercial license and the GNU Public License (later modules will cover licenses in more detail). +#### 支持 -**Hosting** +企业往往希望利用开源提供的技术创新，但更关心在开源产品上运行业务。在这种情况下，他们求助于 RedHat 和 IBM 等公司，它们提供支持、技术指导、专业服务和培训，以帮助企业在开源平台上运行业务应用程序。 -In this model, companies provide the open source product in a Cloud-hosted SaaS (Software as a Service model). The primary examples of this are companies such as Amazon (Amazon Web Services) and Google (Google Cloud) that host open source technologies in hardened, scalable, enterprise-grade configurations. +#### 开放核心 -**Support** +这通常涉及一个功能强大的核心产品，它是免费和开源的。围绕核心，商业实体提供闭源软件，以增加或扩展其功能。这些附加组件然后作为商业软件出售，它们也可以与支持模型结合以提供扩展的培训和技术支持。 -Enterprises often want to take advantage of the technological innovation provided by open source, but are more concerned with running their business on open source products. In this case, they turn to companies like RedHat and IBM, who offer support, technical guidance, professional services and training to help enterprises run business applications on top of an open source platform. +### 2.2 比较开源商业模式 -**Open Core** +在比较这些开源商业模式时，重要的是要注意不同的企业选择特定模式的原因不同，并且如上所述，有时会出现组合模型的情况（例如 Open Core & Support）。以下是企业选择每种模式的一些主要原因： -This typically involves a capable core product which is free and open source. Around the core, a commercial entity provides closed source software that adds to or extends its capabilities. These add-ons are then sold as commercial software, and they can also be combined with the support model to provide training and technical support of the extensions. +#### 消费 -### Comparing Open Source Business Models +当您的企业拥有差异化的知识产权但需要降低成本和复杂性时，战略性地使用开源软件并在该开源基础平台之上构建您的产品或服务，您可以访问共享创新，您可以利用这些创新来构建引人注目的产品，而无需自己建造一切。 -In comparing these open source business models, it’s important to note that different businesses have different reasons for choosing a particular model, and as noted above, there are sometimes cases where models are combined (e.g. Open Core & Support). Here are some primary reasons why businesses choose each model: +#### 许可 -**Consumption** +利用双重许可策略，您有机会获得产品“社区”版本的消费和共享投入的价值，同时销售产品的“企业”版本以实现收入并继续资助“社区版。它还使您能够让客户“先试后买”，并有可能发展他们的业务以要求访问您的付费企业版。 -When your business has differentiated intellectual property but needs to reduce cost and complexity, strategically consuming open source software and building your product or service on top of that open source base platform gives you access to shared innovation that you can leverage to build compelling products without having to build everything yourself. +#### 托管 -**Licensing** +提供开源项目/产品的托管解决方案允许已构建基础设施以支持代码的公司为自己的利益提供相同的软件作为服务给他们的客户。与许可模式类似，这允许组织从软件中获得收入，这有助于资助他们的托管基础​​设施，并允许他们继续开发开源项目。 -Utilizing a dual-licensing strategy gives you the opportunity to get the value of consumption and shared input for a ‘community’ version of your product, while selling an ‘enterprise’ version of the product to realize revenue and continue to fund work on the ‘community’ version. It also gives you the ability to let customers ‘try before they buy’ and potentially grow their business to require access to your paid enterprise version. +#### 支持 -**Hosting** +如果一家技术公司拥有内部专业知识并因为一个或多个开源项目做出贡献而享有盛誉，则提供这些项目的“强化”企业版本并与技术支持和培训捆绑在一起，使他们能够继续在该开源项目中工作项目，并让他们为客户提供一个坚实的基础平台，然后他们可以在该平台上可靠地运行业务软件。在 RedHat Enterprise Linux 上运行的股票市场就是这种模式的一个很好的例子。 -Providing a hosted solution of an open source project/product allows companies that have built infrastructure to support code for their own benefit to offer that same software as a service for their customers. Similar to the licensing model, this allows organizations to derive revenue for the software, which in terms helps fund their hosting infrastructure and also allows them to continue development of the open source project. +#### 开放核心 -**Support** +这种商业模式可以很好地运作，但如果社区认为在开源代码之上提供的闭源扩展理所当然地成为开源核心的一部分，它也会给组织带来不良声誉。这种模式需要一种微妙的平衡，即提供大型企业愿意支付的附加值，同时仍然允许项目的免费社区版本对个人以及中小型企业有用。 -If a technology company has in-house expertise and a reputation for contributing to one or more open source projects, providing a ‘hardened’ enterprise version of those projects that is bundled with technical support and training allows them to continue their work in that open source project and lets them provide their customers with a solid base platform that they can then run business software on reliably. Stock markets running on RedHat Enterprise Linux are a great example of this model. +# 3. 制定开源战略 -**Open Core** +## 3.1 课程：简介 -This business model can work very well, but it also can develop a poor reputation for an organization if the community feels that the closed source extensions provided on top of the open source code should rightfully be part of the open source core. This model requires a delicate balance of providing added value that large enterprises are willing to pay for while still allowing the free community version of a project to be useful to individuals, as well as small to medium businesses. +在本节中，我们将展示如何创建组织开源战略，讨论这样做的价值和必要性，然后讨论该战略将如何影响开源政策的实施的注意事项。 -# Section: Developing an Open Source Strategy +## 3.2 学习目标： -## Lesson: Introduction +在本节结束时，您应该能够： -### Section Overview +- 解释创建组织开源战略的必要性和价值 +- 描述一个组织可能使用的不同类型的策略 +- 阐明分阶段实施计划，以帮助将战略转化为组织政策 -In this section, we will show how to create an organizational open source strategy, discuss the value and need for doing so, and then discuss considerations for how the strategy will affect the implementation of open source policies. +## 3.3 开源战略概述 -### Learning Objectives +### 3.3.1 什么是开源策略？ -By the end of this section, you should be able to: +战略是一个非常广泛的术语，我们可以讨论（或争论）几个小时，但当我们谈论开源时，我们的意思是非常具体的： -- Explain the need and value for creating an organizational open source strategy +- 简洁、高级的文档 +- 基于组织的业务目标 +- 将业务目标映射到开源软件使用和管理指令 -- Describe the different types of strategies an organization might utilize +参与开源相关活动的每个人都必须能够理解该策略。 它成为就未来开源政策和流程达成一致的参考文件。 在持续的基础上，它是制定新决策以及建立计划支持和承诺的重要工具。 -- Articulate a phased implementation plan to help turn the strategy into organizational policies +许多组织还使用开源战略作为建立实施开源最佳实践和政策的授权的工具。 -## Lesson: Overview of an Open Source Strategy +### 3.3.2 要问的主要问题 -### What is an Open Source Strategy? +在创建实用的开源策略时，必须回答三个主要问题。 （前两个问题可以按任一顺序解决。） -Strategy is a very broad term that we could discuss (or argue about) for hours, but we mean something very specific when we talk about Open Source: + **- 组织希望在哪里使用开源？** -- A concise, high level document +这个问题非常重要，因为管理开源的最佳实践对于不同的用例有很大的不同。例如，在内部使用开源工具几乎没有风险，不需要任何许可合规性制度，但在分布式软件中嵌入开源需要更多的考虑和支持元素。 -- Based on the organization’s business objectives + **- 使用开源实现了哪些业务目标？** -- Maps business objectives to open source software use and management directives +我们已经讨论过公司使用开源软件的原因。明确并认可其中哪些是重要的，将极大地促进对下一个细节级别的决策。 -The strategy must be understandable to everyone that participates in open source related activities. It becomes the reference document for establishing agreement on future open source policies and processes. On an ongoing basis, it is an important tool for making new decisions, and for establishing program buy-in and commitment. + **- 您的组织将如何确保实现开源业务目标？** -Many organizations also use an Open Source strategy as a vehicle to establish a mandate for implementing open source best practices and policies. +这些决定为开源管理程序创建了任务。理想情况下，它们反映了从开源中获得最大优势同时有效管理伴随风险的行业最佳实践。 -### Major Questions to Ask +## 3.4 开源战略的价值 -In creating a practical open source strategy, three major questions must be answered. (The first two questions can be addressed in either order.) +### 3.4.1 开源阶梯 -**Where does the organization want to use Open Source?** +当您将许可、社区动态、人才获取和业务动态等所有因素都考虑在内时，开源可能是一个复杂的话题。 典型组织的开源之旅有几个站点： -This question is critically important because the best practices for managing open source are quite different for various use cases. For instance, using open source tools internally poses little-to-no risk and does not require any license compliance regimen, but embedding open source in software that is distributed requires much more consideration and enabling elements. +![Image description](os-ladder.png) -**What business objectives are met by using Open Source?** +让我们将其中的每一个都分解开来： -We’ve already talked about why companies use open source software. Getting clarity and buy-in as to which of these are important will greatly facilitate decision making on the next levels of detail. +- #### 消费者 -**What will your organization do to ensure achieving Open Source business objectives?** +组织最常见的起点是作为其商业产品中的开源软件用户。积极使用开源组件将提高您区分和减少交付商业产品的总体时间和成本的能力。以下是开源消费策略的必要组成部分： -These are the decisions that create a mandate for an open source management program. Ideally they reflect industry best practices for getting the greatest advantage from open source while efficiently managing accompanying risks. +- 一种战略分类方案，用于指导决定使用哪些开源软件 -## Lesson: The Value of an Open Source Strategy +- 确保公司履行其使用开源软件的所有义务 -### Climbing the Open Source Ladder +- 部署自动化工作流软件以评估/批准开源使用 -Open Source can be a complex topic, when you factor in everything from licensing to community dynamics, talent acquisition and business dynamics. There are several stops on a typical organization’s journey in open source: +- 建立一个开源审查委员会 (OSRB) 作为所有开源活动的交换所 -![Climbing the Open Source Ladder](os-ladder.png) +- 增加对工程、产品管理和法律方面的员工人数和基础设施的投资，以管理封闭源代码/开源软件的组合 -Let’s take each of these and break them down: +- #### 参与者 -**Consumer** +一旦您的公司在产品或服务中成功使用开源软件，您就可以扩展您的策略以参与开源社区。除非您已经从社区聘请了经验丰富的开发人员，否则您首先需要更密切地与社区互动，以提高您的知名度并开始吸引您需要的人才。以下是开源参与策略的必要组成部分： -The most common starting point for organizations is as an open source software user in their commercial products. Aggressively consuming open source components will increase your ability to differentiate and reduce overall time and cost to deliver commercial products. Here are the necessary components of the open source consumption strategy: +- 监控社区交流平台，如聊天服务器、邮件列表、论坛和网站，以随时了解项目进展 -- A strategic classification scheme to guide decisions on what open source software to consume +- 参加相关会议和聚会，与社区建立关系 -- Ensure the company meets all obligations of its use of open source software +- 赞助项目活动和基金会以提高社区内的知名度 -- Deploy automated workflow software for evaluating/approving open source usage +- 教育开发人员如何参与开源项目并为之做出贡献 -- Establish an Open Source Review Board (OSRB) to serve as a clearinghouse for all Open Source activities +- #### 贡献者 -- Create incremental investment in headcount and infrastructure in engineering, product management, and legal to manage a mix of closed source / open source software +随着贵公司参与度的增加以及您开始为开源项目贡献代码，您需要有选择地参与目标项目和社区以推动您的 -**Participant** +公司的需要。为战略性开源项目做出贡献可以帮助您的组织获得额外的价值，因为代码贡献可以帮助塑造项目中满足公司需求的未来功能。 -Once your company is successfully using open source software in products or services, you can expand your strategy to participate in the open source community. Unless you have already hired experienced developers from the community, you will first need to engage more closely with the community to increase your visibility and to begin attracting the talent you need. Here are the necessary components of the open source participation strategy: +以下是开源贡献策略的必要组成部分： -- Monitor community communication platforms like chat servers, mailing lists, forums, and websites to stay informed about project developments +- 聘请一名员工主管来领导开源战略并管理 OSRB -- Attend relevant conferences and meetups to establish a relationship with the community +- 雇用对您的产品至关重要的关键开源社区的贡献者和提交者 -- Sponsor project events and foundations to improve visibility within the community +- 部署开源协作工具以支持开源使用和贡献 -- Educate developers on how to participate in and contribute to open source projects +- 添加开源开发者资源 -**Contributor** +- 增加在工程、产品管理和法律方面的投资，以与现有的外部社区互动 -As your company’s participation increases and you begin contributing code to an open source project, you need to selectively engage with targeted projects and communities to drive your company’s needs. Contributing to strategic open source projects can help your organization gain additional value as code contributions can help shape future features in the project that meet a company’s needs. +- #### 领导者 -Here are the necessary components of the open source contribution strategy: +如果一项开源技术对您的业务或产品变得至关重要，您可能希望在该项目的战略和技术方向上拥有发言权。然而，与传统软件不同的是，您不一定能通过金钱“购买”进入或影响领导层。在开源项目中，那些从事工作的人可以帮助确定方向。 -- Hire a staff director to lead open source strategy and manage the OSRB +开源战略阶梯的最后一步是领导力。此方案建立在所有先前方案的基础上，以利用新兴的技术趋势来建立领导地位。 -- Hire contributors and committers to key open source communities that are critical to your products +通过与项目成员建立信任并保持对项目的高水平持续贡献，可以获得现有开源社区的领导角色。 -- Deploy open source collaboration tools to support open source usage and contributions +这种情况需要对目标开源社区和联盟进行大量投资 -- Add open source developer resources +制定领导议程。以下是开源领导力战略的必要组成部分： -- Incrementally invest in engineering, product management, and legal to engage with existing external communities +- 增加与目标开源社区的互动 +- 有选择地采用开放标准来推动公司的需求 +- 参与开源基金会 +- 建立开源项目、组织或基金会 +- 主要在工程、产品管理和法律方面进行重大投资，以在外部社区和行业联盟中建立领导地位 -**Leader** +### 3.4.2 考虑您当前和未来的需求 -If a piece of open source technology becomes critical to your business or product, you’ll likely want a say in the strategic and technical direction of that project. Unlike traditional software however, you cannot necessarily ‘buy’ your way into or influence the leadership simply with money. In open source projects, those who do the work are the ones who get to help set the direction. +如您所见，开源战略的自然演变建立在一系列需要随着时间增加投资的步骤之上。重要的是要注意，对于您使用的每个开源项目或代码库，您的组织应该扮演什么角色的决定是不同的。 -The final step in the open source strategy ladder is leadership. This scenario builds on all of the prior scenarios to capitalize on emerging trends in technology to establish a leadership position. +在某些情况下，作为一个小型、可靠维护的开源项目的简单消费者可能是可以接受的，但在其他情况下，如果开源项目成为您的产品或技术的核心元素，您可能需要考虑成为一个积极的参与者和/或贡献者。 -Leadership roles in existing open source communities are earned by establishing trust with the project members and by maintaining a high level of continuous contribution to the project. +如果开源项目是您的业务和产品的基础，那么努力成为这项工作的领导者是个好主意，特别是如果它是您的组织帮助启动的开源项目。 -This scenario requires significant investment in targeted open source communities and consortia to establish a leadership agenda. Here are the necessary components of the open source leadership strategy: +另一个需要考虑的重要因素是，您的组织在项目中的参与程度会随着时间而改变。制定战略不是“一劳永逸”的事情。准备好定期（6 个月 - 1 年是典型的时间范围）定期审查您的开源策略，以确定您是否需要根据业务或经济状况调整您的参与度。 -- Increase engagement with targeted open source communities +![Image description](involvement-over-time.png) -- Selectively engage with open standards to drive the company’s needs +## 3.5 课程：实施注意事项 -- Engage with open source foundations +### 3.5.1 分阶段实施 -- Establish an open source project, organization, or foundation +开源有一个经常被引用的短语“早发布，经常发布”。在编码的上下文中，这意味着许多小的更改随着时间的推移相互构建，允许对所有更改进行完整和轻松的代码审查，以及更多健壮的代码，因为提供的更改更容易测试和调试。 -- Significant investment primarily in engineering, product management, and legal to establish leadership in external communities and industry consortia +在开发开源策略时可以而且应该使用相同的模型。通过与您的中短期目标相关联的基本战略开始，您可以开始参与开源项目和社区，然后作为您的组织调整您的战略（以及您需要制定的后续政策）对开源方式变得更加自在和自信。 -### Consider Your Current and Future Needs +一般来说，分阶段方法通常遵循前面显示的阶梯图： -As you can see, the natural evolution of an open source strategy is built on a series of steps that require an increased investment over time. It’s important to note that the decision for what role your organization should take is different for every open source project or codebase that you use. +- 制定以有效和高效的方式使用开源的策略（和政策） +- 通过互动/提问、报告错误等开始参与开源项目和社区。 +- 一开始做一些小贡献（即使它们不是代码 - 文档是一个很好的入门方式） +- 随着你对开源项目越来越熟悉和依赖，增加你的贡献 +- 如果您需要“一席之地”（或者您帮助启动了一个项目），请对开源项目做出持续和有价值的贡献和投资 -In some cases, it may be acceptable to be a simple consumer of a small, solidly maintained open source project, but in other cases, if the open source project becomes a core element of your product or technology, you may need to consider being an active participant and/or contributor. +### 3.5.2 战略的实施注意事项 -If the open source project is fundamental to your business and products, it’s a good idea to strive to be a leader for that effort, especially if it’s an open source project your organization helped to start. +虽然我们将在下一节中介绍开源组织策略的创建，但这是一个很好的机会，可以考虑您的策略对您将要实施的策略的影响。 -Another important element to consider is that the level of involvement your organization may have in a project will change over time. Building a strategy is not a ‘one and done’ event. Be prepared to periodically review your open source strategy at regular intervals (6 months - 1 year is the typical time frame) to determine if you need to adjust your participation based on business or economic factors. +您需要考虑的最大因素是时间和金钱。在实施您的策略时，您需要使用多少时间？您准备为实施您选择的战略投入多少资源（资金和人员）？ -![Involvement increases over time](involvement-over-time.png) +#### 时间 -## Lesson: Implementation Considerations +与技术中的几乎任何其他事物一样，有效地使用开源需要投入时间——这既涉及人力资源（员工），也涉及有效理解和规划您将使用的开源项目的发布周期.并非每个项目都具有相同的发布节奏，当您制定政策以确定您使用哪些版本的代码以及何时使用时，您需要意识到这一点。 -### Phased Implementation +虽然我们将在其他模块中介绍安全性和与新的开源版本保持同步，但请注意，您必须考虑在哪些时间范围内就开源项目的消费和员工参与做出决定. -Open Source has an often quoted phrase ‘release early, release often.’ In the context of coding, this translates to many small changes that build upon each other over time, allowing for complete and easy code review of all changes, as well as more robust code because the changes provided are easier to test and debug. +#### 钱 -The same model can and should be used when developing your open source strategy. By starting with a basic strategy that is tied to your short-to-medium term goals, you can begin to engage with open source projects and communities and then adjust your strategy (and the ensuing policies you’ll need to develop) as your organization becomes more comfortable and confident with the ways of open source. +在开源介绍课程中，我们简要介绍了开源可能“免于”许可成本，但这绝不意味着它没有其他相关成本。 -In general, the phased approach usually follows the ladder graphic shown previously: +有效地参与开源，无论是简单地有效地和战略性地使用它，还是推动特定标准都需要花钱，主要是在人员配备方面。您不需要从庞大的员工开始（稍后会详细介绍），但您应该考虑在开始时在软件工程师和支持人员（法律、业务、项目管理）方面的需求制定政策以帮助管理组织的开源工作。 -- Build a strategy (and policies) for consuming open source in an effective and efficient way +考虑时间和金钱因素（并随着时间的推移慢慢调整明智的计划）是确保从您的开源战略中获得的政策长期成功的最佳方法。 -- Begin to participate in open source projects and communities by interacting/asking questions, reporting bugs, etc. +### 3.5.3 战略目标示例 -- Make small contributions at first (even if they are not code - documentation is a great way to get started) +以下是您在制定战略的过程中可以定义的一些目标示例——这绝不是一个详尽的列表——您的组织可能拥有所有这些，或者可能没有包含在此列表中的其他目标： -- As you become more familiar and dependent upon an open source project, increase your contributions +- 通过与技术领导者合作增加创新 +- 使用已经开发和测试过的代码加速部署 +- 通过使用免费的、已经调试过的代码来降低开发成本 +- 通过使用商业工具和组件的免费替代品来降低部署成本 +- 利用社区维护降低代码维护成本 +- 提供与其他开源软件的互操作性 +- 促进合作伙伴或客户创建新功能 -- If you need a ‘seat at the table’ (or you helped start a project), make sustained and valuable contributions and investments in the open source project +### 3.5.4 采取行动的例子 -### Implementation Considerations of Your Strategy +虽然我们将在下一节中更详细地介绍如何定义开源策略，但这里有一些示例操作，您可以在构建策略时为支持您定义的目标而采取以下措施： -While we will cover the creation of open source organizational policies in the next section, this is a good opportunity to consider the ramifications of your strategy on policies you’ll be putting in place to implement your strategy. +- 评估政策和采购流程 + - 在开源、可用的商业和内部开发选项中进行很好的选择 + - 确保许可条款与您的使用和 IP 策略兼容 + - 考虑支持和生命周期成本 + - 代码跟踪策略和流程，可准确了解在何处使用什么软件 +- 确保您遵循既定政策的审核流程 +- 确保始终满足所有 OSS 许可要求的合规流程 +- 行动是开源策略中“橡胶上路”的地方。针对特定目标创建了开源管理计划的授权并塑造了它。 -The biggest considerations you’ll need to think about are time and money. How much time do you have to use when implementing your strategy? And how much resources (money and staff) are you prepared to put towards implementation of your chosen strategy? +上述操作是完整开源管理程序的最基本要素；然而，一些组织可能不需要所有这些元素。例如，从不在其产品中分发开源的组织通常不需要实施许可合规流程。一些组织增加了其他行动，例如：软件支持和维护、确保软件安全的步骤、围绕开源贡献或领导力的目标，或执行人员参与的特定任务。 -**Time** +一些组织会在其战略声明中对行动进行优先级排序，以表明执行的紧迫性或顺序。一些组织发现将所有者分配给各个操作很有用。 -Like almost anything else in technology, working effectively with open source takes an investment of time - this is both in terms of human resources (staff) as well as effectively understanding and planning for the release cycles of the open source projects you’ll be using. Not every project has the same release cadence, and you’ll need to be cognizant of that as you put policies in place to determine which versions of code you consume, and when. +随着您的开源管理程序的开发进入下一阶段，这些行动声明将被纳入实施该战略的政策和流程中。 -While we’ll cover security and keeping up-to-date with new open source releases in other modules, be aware that you’ll have to consider what time frames you’ll make decisions in regarding both consumption and staff participation in open source projects. +建立新市场或事实上的标准 -**Money** +招聘和留住顶尖技术人才 -In the Open Source Introduction module, we briefly covered that open source may be ‘free’ from a licensing cost, but by no means does that mean that it doesn’t have other costs associated with it. +# 4. 制定开源政策 -Effectively participating in open source, whether simply consuming it effectively and strategically, or driving a particular standard costs money, primarily in the staffing area. You don’t need to start with a giant staff (more on that later), but you should be considering the needs you’ll have both in terms of software engineers and support staff (legal, business, project management) as you begin to put policies into place to help govern your organization’s open source efforts. +## 4.1 课程：简介 -Considering time and money elements (and starting slowly with sensible plans to adjust over time) is the best method of making sure that the policies derived from your open source strategy succeed in the long run. +在本节中，我们将讨论如何制定开源策略，为执行您选择的开源策略设置框架。 将特别强调影响这些政策的成功和组织采用的关键因素。 -### Strategic Objective Examples +## 4.2 学习目标 -Here are some examples of objectives you may define as you go through the process of building your strategy - this is by no means an exhaustive list - your organization may have all of these, or potentially others not included in this list: +在本节结束时，您应该能够： -- Increase innovation through collaboration with technology leaders +- 描述实施开源政策的过程，以推动您选择的策略的执行 +- 了解在定义政策时需要考虑哪些关键因素 +- 解释如何最好地设计鼓励组织广泛采用的策略 +- 阐明行业最佳实践在开源政策制定中的作用 -- Speed deployment by using already developed and tested code +## 4.4 课程：开源政策领域概述 -- Lower development costs by using free, already debugged code +### 4.4.1 开源政策应该关注什么？ -- Lower deployment cost by using free alternatives to commercial tools and components +开始他们的开源之旅的组织有时会陷入从“FUD”（恐惧、不确定性和怀疑）的角度定义政策的细节中。虽然在未来的模块中将更详细地介绍开源合规性等领域，但我们想从更有效利用的角度对所有组织在制定开源政策时应考虑的领域进行总体概述，不仅仅是规避风险。 -- Lower code maintenance costs by taking advantage of community maintenance +我们还将尝试解决您如何考虑应该首先关注哪些政策，以及如何在整个组织中社会化这些政策以获得最大效果。 -- Offer interoperability with other open source software +为此，我们将首先介绍任何组织开源政策中应包含的要素——请注意，这不一定是一个详尽的列表，根据您的具体业务情况，可能还有其他项目： -- Facilitate the creation of new capabilities by partners or customers +- 发现 +- 审查和批准 +- 商业采购 +- 代码管理与维护 +- 社区互动 +- 合规 +- 高管参与 -- Establish new markets or de facto standards +### 4.4.2 发现 -- Recruit and retain top technical talent +开源发现和评估涵盖了您的团队如何以及在何处找到感兴趣的开源软件，以及该软件被审查以包含在您组织的软件组合中的标准。发现不应该是一次成功或失败的努力。从正确的方向和标准（相对于临时）开始可以简化这个有时困难的过程并避免未来出现问题。 -### Examples of Actions To Take +发现有用的开源很少从从头开始开始。大多数组织至少已经使用了一些开源软件，这些代码可以构成内部（批准的）存储库的基础。在查看现有产品组合之外，工程师很容易发挥创造力，但为了降低风险和提高效率，最佳实践要求通过商业供应商分发（Red Hat、Google 等组织）建立一组可信来源，或通过云原生计算基金会等软件基金会。 -While we will go into more detail about how to define open source policies in the next section, here are some sample actions you could take in support of the objectives you define while building your strategy: +此外，还有一系列社区、政府和商业工具可用于查找和选择合适的开源项目代码和版本。例如，OpenHub 提供了数千个流行项目的出色元数据，而 Github 本身提供了有关项目发布的仪表板信息。可以从 NIST 漏洞数据库和开源漏洞数据库项目中收集关键安全信息。 -- An evaluation policy and acquisition process that +让组织的所有级别都参与制定这些发现策略很重要——简单地告诉工程师，他们不能使用开源，除非来自特定的内部存储库，而没有进一步解释，并且没有让他们参与决策过程，很可能会导致“创造性”尝试规避此政策，这使以后更难以遵守。 - - Chooses well among open source, available commercial and internal development options +### 4.4.3 审查和批准 - - Insures licensing terms compatible with your use and IP strategy +无论你的发现过程多么小心或勤奋，开源代码面临的真正考验必须来自你的审查和批准过程。 批准和审查是您抵御开源可能带来的安全、法律和运营风险的第一道防线。 - - Considers support and lifecycle costs +与发现一样，利用以前审查过的代码可以加快这个过程，所以如果你的开源团队还没有这样做，最佳实践要求创建批准的组件和版本列表、审查和批准的许可证类型以及以前使用的评估原理 和结果。 -- A code tracking policy and process that provides accurate knowledge of what software is used where +建立明确的标准（并让从工程师到项目经理的所有利益相关者参与）可以避免发现过程中出现问题并加快审查速度。 此外，重要的是要考虑在此政策中为低风险批准建立捷径，以加快此过程、降低成本并为工程团队遵守这些政策提供更多动力。 -- An audit process that insures that you follow set policies +### 4.4.4 商业采购 -- A compliance process that insures that all OSS license requirements are consistently met +当您第一次想到发现和集成开源代码时，很自然地首先想到的是通过 Internet 自由获取的代码。但是大量的开源代码通过商业采购进入组织。开源通常伴随着商业应用程序和/或是商业应用程序的一个组成部分，并且也经常通过合同开发进入可交付成果。 -Action is where "the rubber hits the road" in an open source strategy. Targeting specific objectives creates the mandate for and shapes the open source management program. +商业来源的开源所伴随的风险和合规义务与直接获得的开源所伴随的风险和合规义务没有什么不同。最大的不同在于，您的组织不是直接接触和下载开源代码，而是通过长期存在的传统采购流程隐式，甚至是静默地接收该代码。 -The actions above are the most basic elements of a full open source management program; however, some organizations may not need all of these elements. For instance, an organization that never distributes open source in its products does not usually need to implement a license compliance process. Some organizations add other actions such as: software support and maintenance, steps to insure software security, objectives around open source contributions or leadership, or a specific mandate for executive involvement. +对于商业采购的开源，行业最佳实践要求与您组织的供应链和采购人员合作，以制定和执行以下政策： -Some organizations will prioritize the actions in their strategy statement to indicate urgency or order of execution. Some organizations find it useful to assign owners to the individual actions. +- 报告第三方代码中存在开源元素 +- 知识产权验证，并在适当的情况下，赔偿 +- 代码扫描和审查供应商治理计划以补充报告（如果有） +- 与下游组件跟踪、发布审计和其他合规活动的文档和集成 -As the development of your open source management program moves to the next phases, these action statements are driven into the policy and processes that implement this strategy. +### 4.4.5 代码管理与维护 -# Section: Developing Open Source Policies +“代码所有权”的概念源于过去15年里许多使用开源软件的公司的实践。在最高的层次上，这种做法为开放源代码在您的组织中提供了一个“面孔”，一个与代码以及开发和维护代码的社区关系密切的“可以接触”的人。代码所有权角色通常还包括协调对该代码的支持，直接或通过第三方。 -## Lesson: Introduction +对“所有权”的需求源于开源的“自服务”特性。管理策略应该规定这些组件需要什么样的管理类型，以及代码所有者的角色和职责。 -### Section Overview +与代码管理和维护相关的其他任务是 -In this section, we will discuss how to develop open source policies that set the framework for executing your chosen open source strategy. Special emphasis will be given to key factors that affect the success and organizational adoption of these policies. +- 归档外部来源的开放源代码 +- 创建当前主副本(包括更新、补丁等)供内部使用，作为共享和重用的基础 +- 通过审计跟踪跟踪所有权、批准和其他决策 -### Learning Objectives +附带的支持模型必须是灵活的、可伸缩的和可持续的，具有低风险和低开销。选项包括: -By the end of this section, you should be able to: +- 内部支持(如果有资源，专业技能强且风险低) +- 商业支持聚合器 +- 有重点的供应商支持关键业务组件和/或技术复杂组件或具有高业务/技术风险的组件的平台 -- Describe the process for implementing open source policies that drive the execution of your chosen strategy +### 4.4.6 社区互动 -- Understand what key considerations you need to consider when defining your policies +开源软件通常由志同道合的开发人员社区创建和维护。参与这些社区可为集成和部署其开源软件的组织带来一系列好处，从教育到支持再到错误修复等等。 -- Explain how you can best design policies that encourage widespread adoption in your organization +社区互动不是二元决策。相反，参与是一个连续体。您和您的同事可以选择参与一系列活动中的各种角色，从作为 OSS 消费者的适度开始到持续参与甚至领导。虽然参与水平可以有机地发展，但最好是社区互动水平与组织业务目标保持一致并基于成本效益分析。 -- Articulate the role of industry best practices to open source policy development +以下是需要考虑的一些交互级别： -## Lesson: Overview of Open Source Policy Areas +- 不参与（不推荐） + - 以个人身份参与 +- 不允许与公司有任何联系 +- 代表您的公司参与社区 + - 无 IP 传输 + - 贡献需求或错误修复 + - 传送公司开发的二进制文件、库等。 +- 为社区提供赞助或支持 +- 将公司IP作为OSS发布，建立公司管理的开源项目 -### What Should My Open Source Policy Focus On? +### 4.4.7 合规 -Organizations starting on their journey of open source sometimes get bogged down in the minutia of defining policies from the perspective of ‘FUD’ (Fear, Uncertainty, and Doubt). While there will be more detailed coverage of areas like open source compliance in future modules, we’d like to give a general overview of the areas that should be considered by all organizations in crafting their open source policies from the perspective of more effective utilization, not just avoidance of risk. +合规性侧重于遵守开源政策和开源许可条款。对于分发软件的组织而言，许可证合规性是开源管理中最明显的部分，并且通常为建立开源计划办公室提供动力（在下一课程模块中将详细介绍这一点）。 -We’ll also try to address how you can consider both which policies you should focus on first, as well as how to socialize these policies across your organization for maximum effect. +然而，合规性并不是良好治理的“全部”或“全部”——没有人主要为了遵守其许可而使用开源软件。合规性应该与开源管理的其他方面同等对待，而不是作为“警察行动”。 -To do this, we’ll first present the elements that should be in any organizations open source policies - note that this isn’t necessarily an exhaustive list, and there could be additional items depending on your specific business situation: +对于不分发软件的组织，合规性侧重于确保遵循开源政策和流程，以确保软件系统和应用程序的安全性、可靠性和可支持性。 -- **Discovery** +合规政策需要明确和详细，并制定规则以遵守组织政策和开源许可条款。对合规性的需求强调了能够在每个版本中识别和编目第三方代码（包括开源）以及附带条款（例如，源代码披露、归属等）的要求。 -- **Review & Approval** +#### 4.4.8 高管参与 -- **Commercial Procurement** +开源管理不仅仅是真正接触代码的开发人员的领域。它也不是唯一属于与保护知识产权 (IP) 相关的公司律师的职权范围。成功的开源管理是一项协作努力，需要许多角色和学科的参与。 -- **Code Management & Maintenance** +一组经常被忽视的参与者是组织的高管。高管们最初可能认为开源技术仅仅是技术实现的一个细节，并满足于通过指挥链参与开源管理。开明的高管将意识到开源的风险/收益平衡及其创新和差异化的潜力，从而使高管更多地参与围绕开源管理政策的关键决策。 -- **Community Interaction** +对于高管来说，考虑他们在以下政策领域的角色很重要： -- **Compliance** +- 参与整体开源政策的创建和演变 +- 参与开源审批 + - 通常通过法律和业务线 +- 参与有关开源贡献、项目赞助等的高层决策 +- 接收和审查关于开源活动的定期报告 -- **Executive Engagement** +## 4.5 课程：政策实施注意事项 -### Discovery +### 4.5.1 政策制定中的人为因素 -Open Source Discovery and Evaluation covers how and where your team finds open source software of interest and by what criteria that software is vetted for inclusion in your organization’s software portfolio. Discovery should not be a hit or miss endeavor. Starting with the right direction and criteria (vs. ad hoc) streamlines this sometimes difficult process and avoids problems down the road. +与开源相关的政策创建有一些有趣的人类动态，它们不同于传统的 HR 或您的组织可能习惯创建的其他政策。开源的协作和“社区主导”性质更侧重于完成工作，而不是一系列严格或正式的流程。 -Discovering useful open source seldom starts from a blank slate. Most organizations already use at least some open source software and this code can form the basis of an internal (approved) repository. When looking outside the existing portfolio, there is a temptation for engineers to get creative, but to reduce risk and increase efficiency, best practices dictate establishing a set of trusted sources, either through commercial supplier distributions (organizations like Red Hat, Google or others), or through software foundations like Cloud Native Computing Foundation. +协作是这里的关键要素。与其严格地将这些政策视为惩罚或消除风险的方法，还需要将它们视为不同群体的机会，包括工程师、项目经理、法律专家甚至高管，就如何充分利用这些政策进行透明和坦率的讨论组织参与开源的情况。 -Moreover, a range of community, government and commercial tools exist for finding and choosing appropriate open source project code and versions. For example, OpenHub provides excellent metadata on thousands of popular projects, and Github itself offers dashboard info on project releases. Key security info can be gleaned from the NIST vulnerability database and the open source vulnerability database project. +确实，在某些情况下，管理层可能不得不做出与其他团队（通常是工程部门）并不总是一致的政策决策，但让每个人都可以就政策的创建方式发表意见，这将使每个人都更容易遵守并查看这些政策对组织的意义。 -It’s important to engage all levels of the organization in developing these discovery policies - simply telling engineers that they cannot use open source except from specific internal repositories without further explanation, and without involving them in the decision process, will likely lead to ‘creative’ attempts to circumvent this policy, which makes compliance harder later on. +### 4.5.2 经济和生产力考虑 -### Review & Approval +制定开源政策时要考虑的另一个因素是它们的实施将如何影响工作效率，从而间接影响您的组织的经济影响。 -No matter how careful or diligent your discovery process, the real test faced by open source code must come from your review and approval processes. Review and approval are your first lines of defense against security, legal and operational risk that can accompany open source. +构建涵盖所有可能情况并需要大量人力和技术基础设施的完全“防弹”政策似乎是“最安全”的方法，但这些可能会产生意想不到的后果，包括使软件开发变得缓慢、笨拙和令人不快，以至于您运行如果没有这种严格的政策，组织可能会失去关键的软件人才。 -As with discovery, leveraging previously-vetted code can speed up this process, so if your open source team has not already done so, best practices dictate creating lists of approved components and versions, reviewed and approved license types, and previously-employed evaluation rationale and results. +此外，为此类重量级政策构建必要的流程基础设施在工具和详细的人工监督方面都具有经济成本。对抗构建“完美策略”诱惑的最佳方法是考虑经常重复的开源口头禅“早发布，经常发布”。考虑实施开源策略所需的最少策略集，然后随着您的管理团队和开发组织在开源参与的阶梯上进步，以这些为基础。 -Building clear criteria (and involving all stakeholders from engineers to program managers) avoids issues during discovery and speeds review. Additionally, it’s important to consider building shortcuts in this policy for low risk approvals that can speed up this process, reduce cost, and provide more incentive for engineering teams to adhere to these policies. +# 5. 开源项目办公室介绍 -### Commercial Procurement +## 5.1 课程：简介 -When you first think of discovering and integrating open source code, it’s natural to think primarily of code acquired freely over the Internet. But a substantial amount of open source code makes its way into organizations through commercial sourcing. Open source often accompanies and/or is an integral part of commercial applications and also frequently finds its way into deliverables from contracted development. +在本节中，我们将讨论开源项目办公室 (OSPO) 在帮助定义战略、实施相关政策和指导组织参与开源方面的作用。 在本系列的后续课程中，将更详细地介绍如何设置和运行 OSPO。 -The risks and compliance obligations that accompany commercially-sourced open source are no different from those that come with directly acquired open source. The big difference is that rather than reaching out and downloading open source code directly, your organization receives that code implicitly, even silently, usually through long-standing conventional procurement processes. +## 5.2 学习目标 -For commercially-sourced open source, industry best practices dictate working with your organization’s supply chain and sourcing personnel to establish and enforce policies for: +在本节结束时，您应该能够： -- Reporting the presence of open source elements in 3rd party code +- 定义开源项目办公室的特征 +- 解释开源项目办公室在指导组织开源工作中的作用 +- 阐明开源项目办公室可以帮助定义开源成功指标的一些方法 -- IP verification, and where appropriate, indemnification +## 5.3 开源项目办公室 (OSPO) 概述 -- Code scanning and review of supplier governance programs to supplement reporting (if any) +### 5.3.1 什么是 OSPO，为什么我的组织需要它？ -- Documentation and integration with downstream component tracking, release audit and other compliance activities +中央开源项目办公室是一个指定的地方，在公司内部支持、培育、共享、解释和发展开源。有了这样的办公室，企业可以明确地制定和执行他们的开源战略，为他们的领导者、开发人员、营销人员和其他员工提供他们需要的工具，使开源在他们的运营中取得成功。 -### Code Management & Maintenance +传统软件开发和开源开发之间最大的区别之一是开源中使用的高度协作性。对于许多企业来说，在接近开源使用时所需的理念改变并不容易或自然而然地发生。 -The concept of "code ownership" emanates from the practices of scores of companies working with open source over the last decade and a half. At the highest level, the practice gives open source code “a face” within your organization, a “go to” person who is close to the code and to the community that develops and maintains it. Also typically included under the code ownership role is coordinating support for that code, directly or through third parties. +这就是开源程序的创建可以成为主要福音的地方。通过创建开源项目办公室，企业可以启用、简化和组织开源的使用，使其直接与公司的长期业务计划联系起来。开源项目办公室旨在成为公司开源运营和结构的中心，帮助将所有需要的组件整合在一起。 -The need for "ownership" arises from the “self-service” nature of open source. Management policy should dictate what type of stewardship these components require and the code owner’s roles and responsibilities. +这可以包括设置代码使用、分发、选择、审计和其他政策，以及培训开发人员、确保法律合规性以及促进和建立社区参与。该办公室还可以提供有关公司内外所有开源事物的宣传和交流。 -Other tasks associated with code management and maintenance are +### 5.3.2 OSPO 的角色 -- Archiving externally sourced open source +归根结底，一个组织良好的开源项目办公室很有价值，因为它可以促进公司内部的开源使用、贡献和创建，以获得战略优势。 -- Creating a current master copy (including updates, patches, etc.) for internal use, as the basis for sharing and reuse +一个成功的办公室可以通过建立支持开发人员及其团队的流程来极大地受益于企业开源的使用。它鼓励标准编码和组织实践、流程和工具集。同时，项目办公室可以帮助避免或消除不必要的、僵化的流程，创意开发人员可能会规避或忽略这些流程，从而威胁项目的安全性和其他方面。 -- Tracking ownership, approvals and other decisions with an audit trail +项目办公室的职责各不相同。这些包括： -The accompanying support model must be flexible, scalable and sustainable, with low risk and overhead. Options include: +- 清楚地传达公司内外的开源战略 +- 拥有并监督战略的执行 +- 促进开源在商业产品和服务中的有效使用 +- 确保向开源社区高质量和频繁地发布代码 +- 与开发者社区互动并看到公司有效地回馈其他项目 +- 在组织内培养开源文化 +- 维护开源许可证合规性审查和监督 -- Internal support (if resources are available, expertise is strong and risk is low) +对于每家公司，开源项目办公室的角色很可能会根据其业务、产品和目标进行自定义配置。没有广泛的模板可以构建适用于所有行业的开源程序，甚至适用于单个行业的所有公司。这可能会使其创建成为一项挑战，但您可以从其他公司中吸取教训，并将它们组合在一起以满足您自己组织的要求。 -- Commercial support aggregator +开源项目办公室的另一个关键作用是，当业务部门开始在其计划中考虑开源时，将实质和事实带入对话中，以便充分了解考虑开源的原因、后果和后果。是实现其目标所必需的。这通常是建立对话框架的问题，以便利益相关者在权衡决定时知道从哪里开始以及考虑什么。 -- Focused vendor support for business-critical components and/or platforms for technically complex components or those with high business/technical risk +### 5.3.2 OSPO 在定义成功指标中的作用 -### Community Interaction +开源项目经理必须证明其工作的投资回报 (ROI)。让我们来看看 OSPO 如何帮助定义组织评估其开源计划、项目和贡献的一些标准方式。 -Open source software is typically created and maintained by communities of like-minded developers. Participation in those communities confers a range of benefits on organizations that integrate and deploy their open source software, ranging from education to support to bug fixes and beyond. +学习衡量什么、如何定义成功以及如何最好地利用这些信息来推进您的开源计划目标、证明有效性并获得支持是任何 OSPO 的关键职能。 -Community interaction is not a binary decision. Participation is, instead, a continuum. You and your colleagues can choose to participate in a variety of roles across a range of activities, from a modest start as consumers of OSS up through ongoing involvement and even leadership. While the level of participation can evolve organically, it is always best if the level of community interaction is aligned with organization business goals and based upon a cost-benefit analysis. +您设定的目标和跟踪的指标将根据您投资开源的原因而有所不同——无论是招募开发人员、通过开放式创新引入新想法和技术、加快上市时间、降低开发成本、或无数其他原因。 -Here are some levels of interaction to consider: +根据您的独特战略设定目标非常重要——并寻求执行团队的支持，以确保开源战略与整体业务战略保持一致。 OSPO 可以提供一个中立的位置来帮助您的组织战略性地考虑这些项目。 -1. No Participation (not recommended) -2. Participate as individuals - - No tie to company allowed -3. Participate in a community on your company’s behalf +有经验的 OSPO 员工在构建指标时通常会考虑以下因素： - 1. No IP conveyance +- 他们的开发人员在外部开源项目中的参与度和影响程度 +- 他们的组织在开源社区中的声誉 +- 他们招募和留住有才华的开发人员的能力 +- 组织自己的开源项目及其开发人员参与的关键业务项目的总体健康状况 +- 他们如何管理开源许可证合规性 - 2. Contribute requirements or bug fixes +### 5.3.3 关于 OSPO 创建的最终想法 - 3. Convey company-developed binaries, libraries, etc. +构建和运行有效的 OSPO 还有许多其他方面。事实上，我们将在本系列的后续课程模块中有专门的部分和课程。目前，要考虑的最重要的事情是，随着您在开源参与的领导/参与阶梯上继续前进，您最终将需要某种形式的 OSPO。 -4. Provide sponsorship or support to a community +与战略和政策定义一样，重要的是要记住前面引用的“尽早发布，经常发布”的格言。您无需立即为拥有数百人的 OSPO 配备人员即可发挥作用。从具有足够经验来帮助指导您的组织的开源领导者开始，以及可以帮助他们的少量员工，对于大多数组织来说通常是一个足够好的开始。 -5. Release company IP as OSS and establish a company-managed open source project - -### Compliance - -Compliance focuses on observance of open source policy and open source license terms. License compliance is the most visible part of Open Source Management for organizations that distribute software, and often provides the impetus for the establishment of open source program offices (more on this in the next lesson module). - -However, compliance is not the "be all" or ”end all” of good governance – no one uses open source software primarily for the privilege of complying with its licenses. Compliance should be treated on a par with the other dimensions of open source management, and not as a “police action”. - -For organizations that do not distribute software, compliance is focused on ensuring that the open source policy and processes are followed in order to assure the security, reliability and supportability of the software systems and applications. - -Compliance policy needs to be explicit and detailed, with rules spelled out for complying both with organizational policy and with the terms of open source licenses. The need for compliance highlights the requirement to be able to identify and catalogue third-party code (including open source) in each release, together with accompanying terms (e.g., source code disclosure, attribution, etc.). - -### Executive Engagement - -Open Source Management is not solely the province of developers who actually touch the code. Nor is it uniquely under the purview of corporate lawyers concerned with protecting intellectual property (IP). Successful open source management is a collaborative effort, requiring participation from many roles and disciplines. - -One often ignored set of participants is the organization’s executives. Executives may initially think of open source technology as merely a detail of technical implementation, and be content to participate in open source management through the chain of command. Enlightened executives will perceive the risk/benefit balance in open source and its potential for innovation and differentiation, resulting in greater executive participation in key decisions around open source management policy. - -It’s important for executives to consider their role in the following policy areas: - -- Involvement with overall open source policy creation and evolution - -- Participation in open source review and approval - - - Typically through legal and lines of business - -- Participation in high-level decisions about open source contributions, project sponsorship, etc. - -- Receiving and reviewing regular reports on open source activity - -## Lesson: Policy Implementation Considerations - -### Human Factors in Policy Creation - -Policy creation in relation to open source has some interesting human dynamics at play that are different from traditional HR or other policies that your organization might be used to creating. The collaborative and ‘community-led’ nature of open source focuses more on getting work done than it does on a set of rigid or formal processes. - -Collaboration is the key element here. Rather than considering these policies strictly as punitive or ways to eliminate risk, they also need to be considered opportunities for different groups, including engineers, program managers, legal experts, and even executives to have transparent and frank discussions about how to get the most out of the organization’s engagement in open source. - -It’s true that in some cases, management may have to make decisions about policies that aren’t always in agreement with other groups (usually engineering), but in giving everyone a voice in how policies are created, it will make it easier for everyone to comply and see how the policies make sense for the organization. - -### Economic and Productivity Considerations - -Another element to consider when crafting your open source policies is how their implementation will affect working productivity, and therefore, indirectly, the economic impact to your organization. - -Building completely ‘bulletproof’ policies that cover every possible case, and require a massive human and technological infrastructure can seem like the ‘safest’ approach, but those can have unintended consequences, including making software development slow, unwieldy and so unpleasant that you run the risk of losing critical software talent to organizations without such rigid policies. - -Additionally, building out the necessary process infrastructure for such heavyweight policies has economic cost both in tools and in detailed human oversight. The best approach to combat the temptation to build the ‘perfect policies’ is to consider the oft-repeated open source mantra of ‘release early, release often.’ Consider what minimum set of policies you need to implement your open source strategy, and then build on those as both your management team and development organization progress up the ladder of open source engagement. - -# Section: Introducing the Open Source Program Office - -## Lesson: Introduction - -### Section Overview - -In this section, we will discuss the role that the Open Source Program Office (OSPO) plays in helping define strategy, implementing associated policies, and guiding an organization's involvement in open source. There will be a more detailed coverage of how to set up and run an OSPO in a later module in this series. - -### Learning Objectives - -By the end of this section, you should be able to: - -- Define the characteristics of an Open Source Program office - -- Explain the role of an Open Source Program Office in guiding an organization's open source efforts - -- Articulate some ways an Open Source Program Office can help define metrics for open source success - -## Lesson: Overview of Open Source Program Office (OSPO) - -### What is an OSPO and Why Does My Organization Need One? - -A central open source program office is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their open source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations. - -One of the biggest differences between traditional software development and open source development is the highly collaborative nature used in open source. For many businesses, the needed change in philosophy when approaching open source use doesn’t come easily or naturally. - -That’s where the creation of an open source program can be a major boon. By creating an open source program office, businesses can enable, streamline and organize the use of open source in ways that tie it directly to a company’s long-term business plans. An open source program office is designed to be the center of the universe for a company’s open source operations and structure, helping to bring all the needed components together. - -This can include setting code use, distribution, selection, auditing and other policies, as well as training developers, ensuring legal compliance and promoting and building community engagement. The office can also provide advocacy and communications about all things open source inside and outside the company. - -### The Role of an OSPO - -Ultimately, a well-organized open source program office is valuable because it can advance open source use, contribution, and creation inside companies for strategic advantage. - -A successful office can greatly benefit corporate open source use by establishing processes that enable developers and their teams. It encourages standard coding and organizational practices, processes, and toolsets. At the same time, a program office can help avoid or remove unneeded, rigid processes which creative developers may circumvent or ignore anyway, threatening security and other aspects of projects. - -The responsibilities of a program office are varied. These include: - -- Clearly communicating the open source strategy within and outside the company - -- Owning and overseeing the execution of the strategy - -- Facilitating the effective use of open source in commercial products and services - -- Ensuring high-quality and frequent releases of code to open source communities - -- Engaging with developer communities and seeing that the company contributes back to other projects effectively - -- Fostering an open source culture within an organization - -- Maintaining open source license compliance reviews and oversight - -For every company, the role of the open source program office will likely be custom-configured based on its business, products, and goals. There is no broad template for building an open source program that applies across all industries — or even across all companies in a single industry. That can make its creation a challenge, but you can learn lessons from other companies and bring them together to fit your own organization’s requirements. - -Another key role for the open source program office is to bring substance and facts to the conversation when business units begin to consider open source in their plans so there is a full understanding of why it is being considered, what the consequences will be, and what is needed to reach its goals. It’s often a matter of framing the conversation so that stakeholders know where to start and what to think about as they weigh their decision. - -### The OSPO’s Role in Defining Success Metrics - -Open source program managers must demonstrate the return on investment (ROI) of their efforts. Let’s take a look at how an OSPO helps define some of the standard ways that organizations evaluate their open source programs, projects, and contributions. - -Learning what to measure, how to define success, and how to best use this information to advance your open source program objectives, demonstrate effectiveness, and gain support is a critical function of any OSPO. - -The goals you set, and metrics you track, will vary according to the reasons you’re investing in open source – whether it’s to recruit developers, bring in new ideas and technologies through open innovation, achieve faster time to market, lower development costs, or myriad other reasons. - -It’s important to set goals according to your unique strategy – and seek buy-in from the executive team to ensure that the open source strategy aligns with the overall business strategy. An OSPO can provide that neutral place to help your organization think about these items strategically. - -Experienced OSPO staff generally consider the following when building metrics: - -- Their developers’ participation and level of influence in external open source projects - -- Their organization’s reputation in open source communities - -- Their ability to recruit and retain talented developers - -- The general health of the organization’s own open source projects and the business-critical projects its developers contribute to - -- How well they manage open source license compliance - -### Final Thoughts on OSPO Creation - -There are many other aspects to building and running an effective OSPO. So many, in fact, that we will have a dedicated section and lessons on this in later course modules in this series. For now, the most important thing to consider is that as you continue your journey up the leadership/participation ladder of open source engagement, you’ll eventually need some form of an OSPO. - -As with strategy and policy definition, it’s important to remember the ‘release early, release often’ adage quoted earlier. You don’t need to staff an OSPO with hundreds of people right away to be effective. Starting with an open source leader with enough experience to help guide your organization, and a small staff that can assist them, is usually a good enough start for most organizations. - -What you will find naturally is that well-functioning OSPO’s engage many different stakeholders (engineering, product management, and even executives) in ways that multiply their effectiveness despite their small size. We’ll talk more about finding and building open source leadership for an OSPO in future modules. +您会自然而然地发现，运作良好的 OSPO 与许多不同的利益相关者（工程、产品管理，甚至高管）互动，尽管规模很小，但它们的效率却成倍增加。我们将在未来的模块中更多地讨论为 OSPO 寻找和建立开源领导力。 diff --git a/sources/OSPO-101/module2/involvement-over-time.png b/sources/OSPO-101/module2/involvement-over-time.png new file mode 100644 index 0000000..81a0920 Binary files /dev/null and b/sources/OSPO-101/module2/involvement-over-time.png differ diff --git a/sources/OSPO-101/module2/module2_section1-zh.md b/sources/OSPO-101/module2/module2_section1-zh.md new file mode 100644 index 0000000..f8e4328 --- /dev/null +++ b/sources/OSPO-101/module2/module2_section1-zh.md @@ -0,0 +1,54 @@ +--- +status: translated +title: "OSPO 101 Training Modules - Module 2" +author: TODO Group +collector: mudongliang +collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo +link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md +--- + +# 介绍 + +## 课程：简介 + +在本节中，我们将提供几个重要的开源商业模式的定义，以及它们之间的比较。 我们还将讨论每种方法的相对优势和劣势，并重点介绍哪些模型可以用于哪些业务场景。 + +## 学习目标 + +在本节结束时，您应该能够： + +- 定义最常用的开源商业模式。 +- 解释这些商业模式之间的异同。 +- 了解哪些模型最适合哪些业务场景。 + +## 课程：定义 + +### 主要的开源商业模式有哪些？ + +有两种方法可以划分开源商业模式的概念——那些使用开源（大多数组织）的公司，以及那些主要生产开源的公司。 先说消费端。 + +#### 消费 + +![Image description](strategic-use.png) + +上文重点介绍的 Gartner 最近的一项研究表明，一流的软件和技术组织使用其产品中大约 80% 的软件来自开源，然后在该软件堆栈之上构建其余 20% 的附加值为他们的客户提供产品。这样做可以让他们将有限的工程资源集中在差异化价值上，同时与开源生态系统的其余部分分担通用代码的开发成本。 + +那些生产开源代码的公司通常分为以下类型的商业模式（尽管他们也可能战略性地使用开源）： + +#### 许可 + +这种模式依赖于商业许可和开源许可下的双重许可软件，通常会产生产品的“社区版”和“企业版”，客户可以根据他们可能需要的功能进行选择产品。一个例子是 Oracle MySQL 数据库，它在商业许可证和 GNU 公共许可证下获得许可（后面的模块将更详细地介绍许可证）。 + +#### 托管 + +在此模型中，公司在云托管的 SaaS（软件即服务模型）中提供开源产品。这方面的主要例子是亚马逊（亚马逊网络服务）和谷歌（谷歌云）等公司，它们以强化的、可扩展的、企业级配置托管开源技术。 + +#### 支持 + +企业往往希望利用开源提供的技术创新，但更关心在开源产品上运行业务。在这种情况下，他们求助于 RedHat 和 IBM 等公司，它们提供支持、技术指导、专业服务和培训，以帮助企业在开源平台上运行业务应用程序。 + +#### 开放核心 + +这通常涉及一个功能强大的核心产品，它是免费和开源的。围绕核心，商业实体提供闭源软件，以增加或扩展其功能。这些附加组件然后作为商业软件出售，它们也可以与支持模型结合以提供扩展的培训和技术支持。s. \ No newline at end of file diff --git a/sources/OSPO-101/module2/module2_section1.md b/sources/OSPO-101/module2/module2_section1.md deleted file mode 100644 index dbc25c8..0000000 --- a/sources/OSPO-101/module2/module2_section1.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -status: collected -title: "OSPO 101 Training Modules - Module 2" -author: TODO Group -collector: mudongliang -collected_date: 20240822 -link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md ---- - -# Section: Introducing Open Source Business Models - -## Lesson: Introduction - -### Section Overview - -In this section, we will provide definitions of several important open source business models, as well as comparisons between them. We will also discuss the relative strengths and weaknesses of each approach, and highlight which models can be used in which business scenarios. - -### Learning Objectives - -By the end of this section, you should be able to: - -- Define the most often used open source business models. - -- Explain the differences and similarities among these business models. - -- Understand which models work best with which business scenarios. - -## Lesson: Definitions - -### What are the Major Open Source Business Models? - -There are two ways to slice the notion of open source business models - those companies who consume open source (most organizations), vs. those who primarily produce open source. Let’s tackle the consumption side first. - -**Consumption** - -![Moving to Strategic use of Open Source](strategic-use.png) - -A recent Gartner study, highlighted above, showed that best in class software and technology organizations consume roughly 80% of the software they use in their products from open source, and then build the remaining 20% of their value add on top of that software stack to provide products to their customers. Doing this allows them to focus limited engineering resources on differentiated value while sharing the development costs of common code with the rest of the open source ecosystem. - -Those companies producing open source code generally fall into the following types of business models (though they also likely strategically consume open source as well): - -**Licensing** - -This model relies on dual-licensing software under both a commercial license as well as an open source license, usually resulting in a ‘community edition’ and an ‘enterprise edition’ of the product that customers can choose depending upon what features they may need in the product. An example is the Oracle MySQL database, licensed under both a commercial license and the GNU Public License (later modules will cover licenses in more detail). - -**Hosting** - -In this model, companies provide the open source product in a Cloud-hosted SaaS (Software as a Service model). The primary examples of this are companies such as Amazon (Amazon Web Services) and Google (Google Cloud) that host open source technologies in hardened, scalable, enterprise-grade configurations. - -**Support** - -Enterprises often want to take advantage of the technological innovation provided by open source, but are more concerned with running their business on open source products. In this case, they turn to companies like RedHat and IBM, who offer support, technical guidance, professional services and training to help enterprises run business applications on top of an open source platform. - -**Open Core** - -This typically involves a capable core product which is free and open source. Around the core, a commercial entity provides closed source software that adds to or extends its capabilities. These add-ons are then sold as commercial software, and they can also be combined with the support model to provide training and technical support of the extensions. - -### Comparing Open Source Business Models - -In comparing these open source business models, it’s important to note that different businesses have different reasons for choosing a particular model, and as noted above, there are sometimes cases where models are combined (e.g. Open Core & Support). Here are some primary reasons why businesses choose each model: - -**Consumption** - -When your business has differentiated intellectual property but needs to reduce cost and complexity, strategically consuming open source software and building your product or service on top of that open source base platform gives you access to shared innovation that you can leverage to build compelling products without having to build everything yourself. - -**Licensing** - -Utilizing a dual-licensing strategy gives you the opportunity to get the value of consumption and shared input for a ‘community’ version of your product, while selling an ‘enterprise’ version of the product to realize revenue and continue to fund work on the ‘community’ version. It also gives you the ability to let customers ‘try before they buy’ and potentially grow their business to require access to your paid enterprise version. - -**Hosting** - -Providing a hosted solution of an open source project/product allows companies that have built infrastructure to support code for their own benefit to offer that same software as a service for their customers. Similar to the licensing model, this allows organizations to derive revenue for the software, which in terms helps fund their hosting infrastructure and also allows them to continue development of the open source project. - -**Support** - -If a technology company has in-house expertise and a reputation for contributing to one or more open source projects, providing a ‘hardened’ enterprise version of those projects that is bundled with technical support and training allows them to continue their work in that open source project and lets them provide their customers with a solid base platform that they can then run business software on reliably. Stock markets running on RedHat Enterprise Linux are a great example of this model. - -**Open Core** - -This business model can work very well, but it also can develop a poor reputation for an organization if the community feels that the closed source extensions provided on top of the open source code should rightfully be part of the open source core. This model requires a delicate balance of providing added value that large enterprises are willing to pay for while still allowing the free community version of a project to be useful to individuals, as well as small to medium businesses. \ No newline at end of file diff --git a/sources/OSPO-101/module2/module2_section2-zh.md b/sources/OSPO-101/module2/module2_section2-zh.md new file mode 100644 index 0000000..2ecafcc --- /dev/null +++ b/sources/OSPO-101/module2/module2_section2-zh.md @@ -0,0 +1,209 @@ +--- +status: translated +title: "OSPO 101 Training Modules - Module 2" +author: TODO Group +collector: mudongliang +collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo +link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md +--- + +# 制定开源战略 + +## 课程：简介 + +在本节中，我们将展示如何创建组织开源战略，讨论这样做的价值和必要性，然后讨论该战略将如何影响开源政策的实施的注意事项。 + +## 学习目标： + +在本节结束时，您应该能够： + +- 解释创建组织开源战略的必要性和价值 +- 描述一个组织可能使用的不同类型的策略 +- 阐明分阶段实施计划，以帮助将战略转化为组织政策 + +## 开源战略概述 + +### 什么是开源策略？ + +战略是一个非常广泛的术语，我们可以讨论（或争论）几个小时，但当我们谈论开源时，我们的意思是非常具体的： + +- 简洁、高级的文档 +- 基于组织的业务目标 +- 将业务目标映射到开源软件使用和管理指令 + +参与开源相关活动的每个人都必须能够理解该策略。 它成为就未来开源政策和流程达成一致的参考文件。 在持续的基础上，它是制定新决策以及建立计划支持和承诺的重要工具。 + +许多组织还使用开源战略作为建立实施开源最佳实践和政策的授权的工具。 + +### 要问的主要问题 + +在创建实用的开源策略时，必须回答三个主要问题。 （前两个问题可以按任一顺序解决。） + + **- 组织希望在哪里使用开源？** + +这个问题非常重要，因为管理开源的最佳实践对于不同的用例有很大的不同。例如，在内部使用开源工具几乎没有风险，不需要任何许可合规性制度，但在分布式软件中嵌入开源需要更多的考虑和支持元素。 + + **- 使用开源实现了哪些业务目标？** + +我们已经讨论过公司使用开源软件的原因。明确并认可其中哪些是重要的，将极大地促进对下一个细节级别的决策。 + + **- 您的组织将如何确保实现开源业务目标？** + +这些决定为开源管理程序创建了任务。理想情况下，它们反映了从开源中获得最大优势同时有效管理伴随风险的行业最佳实践。 + +## 开源战略的价值 + +### 开源阶梯 + +当您将许可、社区动态、人才获取和业务动态等所有因素都考虑在内时，开源可能是一个复杂的话题。 典型组织的开源之旅有几个站点： + +![Image description](os-ladder.png) + +让我们将其中的每一个都分解开来： + +- #### 消费者 + +组织最常见的起点是作为其商业产品中的开源软件用户。积极使用开源组件将提高您区分和减少交付商业产品的总体时间和成本的能力。以下是开源消费策略的必要组成部分： + +- 一种战略分类方案，用于指导决定使用哪些开源软件 + +- 确保公司履行其使用开源软件的所有义务 + +- 部署自动化工作流软件以评估/批准开源使用 + +- 建立一个开源审查委员会 (OSRB) 作为所有开源活动的交换所 + +- 增加对工程、产品管理和法律方面的员工人数和基础设施的投资，以管理封闭源代码/开源软件的组合 + +- #### 参与者 + +一旦您的公司在产品或服务中成功使用开源软件，您就可以扩展您的策略以参与开源社区。除非您已经从社区聘请了经验丰富的开发人员，否则您首先需要更密切地与社区互动，以提高您的知名度并开始吸引您需要的人才。以下是开源参与策略的必要组成部分： + +- 监控社区交流平台，如聊天服务器、邮件列表、论坛和网站，以随时了解项目进展 + +- 参加相关会议和聚会，与社区建立关系 + +- 赞助项目活动和基金会以提高社区内的知名度 + +- 教育开发人员如何参与开源项目并为之做出贡献 + +- #### 贡献者 + +随着贵公司参与度的增加以及您开始为开源项目贡献代码，您需要有选择地参与目标项目和社区以推动您的 + +公司的需要。为战略性开源项目做出贡献可以帮助您的组织获得额外的价值，因为代码贡献可以帮助塑造项目中满足公司需求的未来功能。 + +以下是开源贡献策略的必要组成部分： + +- 聘请一名员工主管来领导开源战略并管理 OSRB + +- 雇用对您的产品至关重要的关键开源社区的贡献者和提交者 + +- 部署开源协作工具以支持开源使用和贡献 + +- 添加开源开发者资源 + +- 增加在工程、产品管理和法律方面的投资，以与现有的外部社区互动 + +- #### 领导者 + +如果一项开源技术对您的业务或产品变得至关重要，您可能希望在该项目的战略和技术方向上拥有发言权。然而，与传统软件不同的是，您不一定能通过金钱“购买”进入或影响领导层。在开源项目中，那些从事工作的人可以帮助确定方向。 + +开源战略阶梯的最后一步是领导力。此方案建立在所有先前方案的基础上，以利用新兴的技术趋势来建立领导地位。 + +通过与项目成员建立信任并保持对项目的高水平持续贡献，可以获得现有开源社区的领导角色。 + +这种情况需要对目标开源社区和联盟进行大量投资 + +制定领导议程。以下是开源领导力战略的必要组成部分： + +- 增加与目标开源社区的互动 +- 有选择地采用开放标准来推动公司的需求 +- 参与开源基金会 +- 建立开源项目、组织或基金会 +- 主要在工程、产品管理和法律方面进行重大投资，以在外部社区和行业联盟中建立领导地位 + +### 考虑您当前和未来的需求 + +如您所见，开源战略的自然演变建立在一系列需要随着时间增加投资的步骤之上。重要的是要注意，对于您使用的每个开源项目或代码库，您的组织应该扮演什么角色的决定是不同的。 + +在某些情况下，作为一个小型、可靠维护的开源项目的简单消费者可能是可以接受的，但在其他情况下，如果开源项目成为您的产品或技术的核心元素，您可能需要考虑成为一个积极的参与者和/或贡献者。 + +如果开源项目是您的业务和产品的基础，那么努力成为这项工作的领导者是个好主意，特别是如果它是您的组织帮助启动的开源项目。 + +另一个需要考虑的重要因素是，您的组织在项目中的参与程度会随着时间而改变。制定战略不是“一劳永逸”的事情。准备好定期（6 个月 - 1 年是典型的时间范围）定期审查您的开源策略，以确定您是否需要根据业务或经济状况调整您的参与度。 + +![Image description](involvement-over-time.png) + +## 课程：实施注意事项 + +### 分阶段实施 + +开源有一个经常被引用的短语“早发布，经常发布”。在编码的上下文中，这意味着许多小的更改随着时间的推移相互构建，允许对所有更改进行完整和轻松的代码审查，以及更多健壮的代码，因为提供的更改更容易测试和调试。 + +在开发开源策略时可以而且应该使用相同的模型。通过与您的中短期目标相关联的基本战略开始，您可以开始参与开源项目和社区，然后作为您的组织调整您的战略（以及您需要制定的后续政策）对开源方式变得更加自在和自信。 + +一般来说，分阶段方法通常遵循前面显示的阶梯图： + +- 制定以有效和高效的方式使用开源的策略（和政策） +- 通过互动/提问、报告错误等开始参与开源项目和社区。 +- 一开始做一些小贡献（即使它们不是代码 - 文档是一个很好的入门方式） +- 随着你对开源项目越来越熟悉和依赖，增加你的贡献 +- 如果您需要“一席之地”（或者您帮助启动了一个项目），请对开源项目做出持续和有价值的贡献和投资 + +### 战略的实施注意事项 + +虽然我们将在下一节中介绍开源组织策略的创建，但这是一个很好的机会，可以考虑您的策略对您将要实施的策略的影响。 + +您需要考虑的最大因素是时间和金钱。在实施您的策略时，您需要使用多少时间？您准备为实施您选择的战略投入多少资源（资金和人员）？ + +#### 时间 + +与技术中的几乎任何其他事物一样，有效地使用开源需要投入时间——这既涉及人力资源（员工），也涉及有效理解和规划您将使用的开源项目的发布周期.并非每个项目都具有相同的发布节奏，当您制定政策以确定您使用哪些版本的代码以及何时使用时，您需要意识到这一点。 + +虽然我们将在其他模块中介绍安全性和与新的开源版本保持同步，但请注意，您必须考虑在哪些时间范围内就开源项目的消费和员工参与做出决定. + +#### 钱 + +在开源介绍课程中，我们简要介绍了开源可能“免于”许可成本，但这绝不意味着它没有其他相关成本。 + +有效地参与开源，无论是简单地有效地和战略性地使用它，还是推动特定标准都需要花钱，主要是在人员配备方面。您不需要从庞大的员工开始（稍后会详细介绍），但您应该考虑在开始时在软件工程师和支持人员（法律、业务、项目管理）方面的需求制定政策以帮助管理组织的开源工作。 + +考虑时间和金钱因素（并随着时间的推移慢慢调整明智的计划）是确保从您的开源战略中获得的政策长期成功的最佳方法。 + +### 战略目标示例 + +以下是您在制定战略的过程中可以定义的一些目标示例——这绝不是一个详尽的列表——您的组织可能拥有所有这些，或者可能没有包含在此列表中的其他目标： + +- 通过与技术领导者合作增加创新 +- 使用已经开发和测试过的代码加速部署 +- 通过使用免费的、已经调试过的代码来降低开发成本 +- 通过使用商业工具和组件的免费替代品来降低部署成本 +- 利用社区维护降低代码维护成本 +- 提供与其他开源软件的互操作性 +- 促进合作伙伴或客户创建新功能 + +### 采取行动的例子 + +虽然我们将在下一节中更详细地介绍如何定义开源策略，但这里有一些示例操作，您可以在构建策略时为支持您定义的目标而采取以下措施： + +- 评估政策和采购流程 + - 在开源、可用的商业和内部开发选项中进行很好的选择 + - 确保许可条款与您的使用和 IP 策略兼容 + - 考虑支持和生命周期成本 + - 代码跟踪策略和流程，可准确了解在何处使用什么软件 +- 确保您遵循既定政策的审核流程 +- 确保始终满足所有 OSS 许可要求的合规流程 +- 行动是开源策略中“橡胶上路”的地方。针对特定目标创建了开源管理计划的授权并塑造了它。 + +上述操作是完整开源管理程序的最基本要素；然而，一些组织可能不需要所有这些元素。例如，从不在其产品中分发开源的组织通常不需要实施许可合规流程。一些组织增加了其他行动，例如：软件支持和维护、确保软件安全的步骤、围绕开源贡献或领导力的目标，或执行人员参与的特定任务。 + +一些组织会在其战略声明中对行动进行优先级排序，以表明执行的紧迫性或顺序。一些组织发现将所有者分配给各个操作很有用。 + +随着您的开源管理程序的开发进入下一阶段，这些行动声明将被纳入实施该战略的政策和流程中。 + +建立新市场或事实上的标准 + +招聘和留住顶尖技术人才 \ No newline at end of file diff --git a/sources/OSPO-101/module2/module2_section2.md b/sources/OSPO-101/module2/module2_section2.md deleted file mode 100644 index 0bb68b7..0000000 --- a/sources/OSPO-101/module2/module2_section2.md +++ /dev/null @@ -1,230 +0,0 @@ ---- -status: collected -title: "OSPO 101 Training Modules - Module 2" -author: TODO Group -collector: mudongliang -collected_date: 20240822 -link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md ---- - -# Section: Developing an Open Source Strategy - -## Lesson: Introduction - -### Section Overview - -In this section, we will show how to create an organizational open source strategy, discuss the value and need for doing so, and then discuss considerations for how the strategy will affect the implementation of open source policies. - -### Learning Objectives - -By the end of this section, you should be able to: - -- Explain the need and value for creating an organizational open source strategy - -- Describe the different types of strategies an organization might utilize - -- Articulate a phased implementation plan to help turn the strategy into organizational policies - -## Lesson: Overview of an Open Source Strategy - -### What is an Open Source Strategy? - -Strategy is a very broad term that we could discuss (or argue about) for hours, but we mean something very specific when we talk about Open Source: - -- A concise, high level document - -- Based on the organization’s business objectives - -- Maps business objectives to open source software use and management directives - -The strategy must be understandable to everyone that participates in open source related activities. It becomes the reference document for establishing agreement on future open source policies and processes. On an ongoing basis, it is an important tool for making new decisions, and for establishing program buy-in and commitment. - -Many organizations also use an Open Source strategy as a vehicle to establish a mandate for implementing open source best practices and policies. - -### Major Questions to Ask - -In creating a practical open source strategy, three major questions must be answered. (The first two questions can be addressed in either order.) - -**Where does the organization want to use Open Source?** - -This question is critically important because the best practices for managing open source are quite different for various use cases. For instance, using open source tools internally poses little-to-no risk and does not require any license compliance regimen, but embedding open source in software that is distributed requires much more consideration and enabling elements. - -**What business objectives are met by using Open Source?** - -We’ve already talked about why companies use open source software. Getting clarity and buy-in as to which of these are important will greatly facilitate decision making on the next levels of detail. - -**What will your organization do to ensure achieving Open Source business objectives?** - -These are the decisions that create a mandate for an open source management program. Ideally they reflect industry best practices for getting the greatest advantage from open source while efficiently managing accompanying risks. - -## Lesson: The Value of an Open Source Strategy - -### Climbing the Open Source Ladder - -Open Source can be a complex topic, when you factor in everything from licensing to community dynamics, talent acquisition and business dynamics. There are several stops on a typical organization’s journey in open source: - -![Climbing the Open Source Ladder](os-ladder.png) - -Let’s take each of these and break them down: - -**Consumer** - -The most common starting point for organizations is as an open source software user in their commercial products. Aggressively consuming open source components will increase your ability to differentiate and reduce overall time and cost to deliver commercial products. Here are the necessary components of the open source consumption strategy: - -- A strategic classification scheme to guide decisions on what open source software to consume - -- Ensure the company meets all obligations of its use of open source software - -- Deploy automated workflow software for evaluating/approving open source usage - -- Establish an Open Source Review Board (OSRB) to serve as a clearinghouse for all Open Source activities - -- Create incremental investment in headcount and infrastructure in engineering, product management, and legal to manage a mix of closed source / open source software - -**Participant** - -Once your company is successfully using open source software in products or services, you can expand your strategy to participate in the open source community. Unless you have already hired experienced developers from the community, you will first need to engage more closely with the community to increase your visibility and to begin attracting the talent you need. Here are the necessary components of the open source participation strategy: - -- Monitor community communication platforms like chat servers, mailing lists, forums, and websites to stay informed about project developments - -- Attend relevant conferences and meetups to establish a relationship with the community - -- Sponsor project events and foundations to improve visibility within the community - -- Educate developers on how to participate in and contribute to open source projects - -**Contributor** - -As your company’s participation increases and you begin contributing code to an open source project, you need to selectively engage with targeted projects and communities to drive your company’s needs. Contributing to strategic open source projects can help your organization gain additional value as code contributions can help shape future features in the project that meet a company’s needs. - -Here are the necessary components of the open source contribution strategy: - -- Hire a staff director to lead open source strategy and manage the OSRB - -- Hire contributors and committers to key open source communities that are critical to your products - -- Deploy open source collaboration tools to support open source usage and contributions - -- Add open source developer resources - -- Incrementally invest in engineering, product management, and legal to engage with existing external communities - -**Leader** - -If a piece of open source technology becomes critical to your business or product, you’ll likely want a say in the strategic and technical direction of that project. Unlike traditional software however, you cannot necessarily ‘buy’ your way into or influence the leadership simply with money. In open source projects, those who do the work are the ones who get to help set the direction. - -The final step in the open source strategy ladder is leadership. This scenario builds on all of the prior scenarios to capitalize on emerging trends in technology to establish a leadership position. - -Leadership roles in existing open source communities are earned by establishing trust with the project members and by maintaining a high level of continuous contribution to the project. - -This scenario requires significant investment in targeted open source communities and consortia to establish a leadership agenda. Here are the necessary components of the open source leadership strategy: - -- Increase engagement with targeted open source communities - -- Selectively engage with open standards to drive the company’s needs - -- Engage with open source foundations - -- Establish an open source project, organization, or foundation - -- Significant investment primarily in engineering, product management, and legal to establish leadership in external communities and industry consortia - -### Consider Your Current and Future Needs - -As you can see, the natural evolution of an open source strategy is built on a series of steps that require an increased investment over time. It’s important to note that the decision for what role your organization should take is different for every open source project or codebase that you use. - -In some cases, it may be acceptable to be a simple consumer of a small, solidly maintained open source project, but in other cases, if the open source project becomes a core element of your product or technology, you may need to consider being an active participant and/or contributor. - -If the open source project is fundamental to your business and products, it’s a good idea to strive to be a leader for that effort, especially if it’s an open source project your organization helped to start. - -Another important element to consider is that the level of involvement your organization may have in a project will change over time. Building a strategy is not a ‘one and done’ event. Be prepared to periodically review your open source strategy at regular intervals (6 months - 1 year is the typical time frame) to determine if you need to adjust your participation based on business or economic factors. - -![Involvement increases over time](involvement-over-time.png) - -## Lesson: Implementation Considerations - -### Phased Implementation - -Open Source has an often quoted phrase ‘release early, release often.’ In the context of coding, this translates to many small changes that build upon each other over time, allowing for complete and easy code review of all changes, as well as more robust code because the changes provided are easier to test and debug. - -The same model can and should be used when developing your open source strategy. By starting with a basic strategy that is tied to your short-to-medium term goals, you can begin to engage with open source projects and communities and then adjust your strategy (and the ensuing policies you’ll need to develop) as your organization becomes more comfortable and confident with the ways of open source. - -In general, the phased approach usually follows the ladder graphic shown previously: - -- Build a strategy (and policies) for consuming open source in an effective and efficient way - -- Begin to participate in open source projects and communities by interacting/asking questions, reporting bugs, etc. - -- Make small contributions at first (even if they are not code - documentation is a great way to get started) - -- As you become more familiar and dependent upon an open source project, increase your contributions - -- If you need a ‘seat at the table’ (or you helped start a project), make sustained and valuable contributions and investments in the open source project - -### Implementation Considerations of Your Strategy - -While we will cover the creation of open source organizational policies in the next section, this is a good opportunity to consider the ramifications of your strategy on policies you’ll be putting in place to implement your strategy. - -The biggest considerations you’ll need to think about are time and money. How much time do you have to use when implementing your strategy? And how much resources (money and staff) are you prepared to put towards implementation of your chosen strategy? - -**Time** - -Like almost anything else in technology, working effectively with open source takes an investment of time - this is both in terms of human resources (staff) as well as effectively understanding and planning for the release cycles of the open source projects you’ll be using. Not every project has the same release cadence, and you’ll need to be cognizant of that as you put policies in place to determine which versions of code you consume, and when. - -While we’ll cover security and keeping up-to-date with new open source releases in other modules, be aware that you’ll have to consider what time frames you’ll make decisions in regarding both consumption and staff participation in open source projects. - -**Money** - -In the Open Source Introduction module, we briefly covered that open source may be ‘free’ from a licensing cost, but by no means does that mean that it doesn’t have other costs associated with it. - -Effectively participating in open source, whether simply consuming it effectively and strategically, or driving a particular standard costs money, primarily in the staffing area. You don’t need to start with a giant staff (more on that later), but you should be considering the needs you’ll have both in terms of software engineers and support staff (legal, business, project management) as you begin to put policies into place to help govern your organization’s open source efforts. - -Considering time and money elements (and starting slowly with sensible plans to adjust over time) is the best method of making sure that the policies derived from your open source strategy succeed in the long run. - -### Strategic Objective Examples - -Here are some examples of objectives you may define as you go through the process of building your strategy - this is by no means an exhaustive list - your organization may have all of these, or potentially others not included in this list: - -- Increase innovation through collaboration with technology leaders - -- Speed deployment by using already developed and tested code - -- Lower development costs by using free, already debugged code - -- Lower deployment cost by using free alternatives to commercial tools and components - -- Lower code maintenance costs by taking advantage of community maintenance - -- Offer interoperability with other open source software - -- Facilitate the creation of new capabilities by partners or customers - -- Establish new markets or de facto standards - -- Recruit and retain top technical talent - -### Examples of Actions To Take - -While we will go into more detail about how to define open source policies in the next section, here are some sample actions you could take in support of the objectives you define while building your strategy: - -- An evaluation policy and acquisition process that - - - Chooses well among open source, available commercial and internal development options - - - Insures licensing terms compatible with your use and IP strategy - - - Considers support and lifecycle costs - -- A code tracking policy and process that provides accurate knowledge of what software is used where - -- An audit process that insures that you follow set policies - -- A compliance process that insures that all OSS license requirements are consistently met - -Action is where "the rubber hits the road" in an open source strategy. Targeting specific objectives creates the mandate for and shapes the open source management program. - -The actions above are the most basic elements of a full open source management program; however, some organizations may not need all of these elements. For instance, an organization that never distributes open source in its products does not usually need to implement a license compliance process. Some organizations add other actions such as: software support and maintenance, steps to insure software security, objectives around open source contributions or leadership, or a specific mandate for executive involvement. - -Some organizations will prioritize the actions in their strategy statement to indicate urgency or order of execution. Some organizations find it useful to assign owners to the individual actions. - -As the development of your open source management program moves to the next phases, these action statements are driven into the policy and processes that implement this strategy. \ No newline at end of file diff --git a/sources/OSPO-101/module2/module2_section3-zh.md b/sources/OSPO-101/module2/module2_section3-zh.md new file mode 100644 index 0000000..431b0df --- /dev/null +++ b/sources/OSPO-101/module2/module2_section3-zh.md @@ -0,0 +1,152 @@ +--- +status: translated +title: "OSPO 101 Training Modules - Module 2" +author: TODO Group +collector: mudongliang +collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo +link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md +--- + +# 制定开源政策 + +## 课程：简介 + +在本节中，我们将讨论如何制定开源策略，为执行您选择的开源策略设置框架。 将特别强调影响这些政策的成功和组织采用的关键因素。 + +## 学习目标 + +在本节结束时，您应该能够： + +- 描述实施开源政策的过程，以推动您选择的策略的执行 +- 了解在定义政策时需要考虑哪些关键因素 +- 解释如何最好地设计鼓励组织广泛采用的策略 +- 阐明行业最佳实践在开源政策制定中的作用 + +## 课程：开源政策领域概述 + +### 开源政策应该关注什么？ + +开始他们的开源之旅的组织有时会陷入从“FUD”（恐惧、不确定性和怀疑）的角度定义政策的细节中。虽然在未来的模块中将更详细地介绍开源合规性等领域，但我们想从更有效利用的角度对所有组织在制定开源政策时应考虑的领域进行总体概述，不仅仅是规避风险。 + +我们还将尝试解决您如何考虑应该首先关注哪些政策，以及如何在整个组织中社会化这些政策以获得最大效果。 + +为此，我们将首先介绍任何组织开源政策中应包含的要素——请注意，这不一定是一个详尽的列表，根据您的具体业务情况，可能还有其他项目： + +- 发现 +- 审查和批准 +- 商业采购 +- 代码管理与维护 +- 社区互动 +- 合规 +- 高管参与 + +### 发现 + +开源发现和评估涵盖了您的团队如何以及在何处找到感兴趣的开源软件，以及该软件被审查以包含在您组织的软件组合中的标准。发现不应该是一次成功或失败的努力。从正确的方向和标准（相对于临时）开始可以简化这个有时困难的过程并避免未来出现问题。 + +发现有用的开源很少从从头开始开始。大多数组织至少已经使用了一些开源软件，这些代码可以构成内部（批准的）存储库的基础。在查看现有产品组合之外，工程师很容易发挥创造力，但为了降低风险和提高效率，最佳实践要求通过商业供应商分发（Red Hat、Google 等组织）建立一组可信来源，或通过云原生计算基金会等软件基金会。 + +此外，还有一系列社区、政府和商业工具可用于查找和选择合适的开源项目代码和版本。例如，OpenHub 提供了数千个流行项目的出色元数据，而 Github 本身提供了有关项目发布的仪表板信息。可以从 NIST 漏洞数据库和开源漏洞数据库项目中收集关键安全信息。 + +让组织的所有级别都参与制定这些发现策略很重要——简单地告诉工程师，他们不能使用开源，除非来自特定的内部存储库，而没有进一步解释，并且没有让他们参与决策过程，很可能会导致“创造性”尝试规避此政策，这使以后更难以遵守。 + +### 审查和批准 + +无论你的发现过程多么小心或勤奋，开源代码面临的真正考验必须来自你的审查和批准过程。 批准和审查是您抵御开源可能带来的安全、法律和运营风险的第一道防线。 + +与发现一样，利用以前审查过的代码可以加快这个过程，所以如果你的开源团队还没有这样做，最佳实践要求创建批准的组件和版本列表、审查和批准的许可证类型以及以前使用的评估原理 和结果。 + +建立明确的标准（并让从工程师到项目经理的所有利益相关者参与）可以避免发现过程中出现问题并加快审查速度。 此外，重要的是要考虑在此政策中为低风险批准建立捷径，以加快此过程、降低成本并为工程团队遵守这些政策提供更多动力。 + +### 商业采购 + +当您第一次想到发现和集成开源代码时，很自然地首先想到的是通过 Internet 自由获取的代码。但是大量的开源代码通过商业采购进入组织。开源通常伴随着商业应用程序和/或是商业应用程序的一个组成部分，并且也经常通过合同开发进入可交付成果。 + +商业来源的开源所伴随的风险和合规义务与直接获得的开源所伴随的风险和合规义务没有什么不同。最大的不同在于，您的组织不是直接接触和下载开源代码，而是通过长期存在的传统采购流程隐式，甚至是静默地接收该代码。 + +对于商业采购的开源，行业最佳实践要求与您组织的供应链和采购人员合作，以制定和执行以下政策： + +- 报告第三方代码中存在开源元素 +- 知识产权验证，并在适当的情况下，赔偿 +- 代码扫描和审查供应商治理计划以补充报告（如果有） +- 与下游组件跟踪、发布审计和其他合规活动的文档和集成 + +### 代码管理与维护 + +“代码所有权”的概念源于过去15年里许多使用开源软件的公司的实践。在最高的层次上，这种做法为开放源代码在您的组织中提供了一个“面孔”，一个与代码以及开发和维护代码的社区关系密切的“可以接触”的人。代码所有权角色通常还包括协调对该代码的支持，直接或通过第三方。 + +对“所有权”的需求源于开源的“自服务”特性。管理策略应该规定这些组件需要什么样的管理类型，以及代码所有者的角色和职责。 + +与代码管理和维护相关的其他任务是 + +- 归档外部来源的开放源代码 +- 创建当前主副本(包括更新、补丁等)供内部使用，作为共享和重用的基础 +- 通过审计跟踪跟踪所有权、批准和其他决策 + +附带的支持模型必须是灵活的、可伸缩的和可持续的，具有低风险和低开销。选项包括: + +- 内部支持(如果有资源，专业技能强且风险低) +- 商业支持聚合器 +- 有重点的供应商支持关键业务组件和/或技术复杂组件或具有高业务/技术风险的组件的平台 + +### 社区互动 + +开源软件通常由志同道合的开发人员社区创建和维护。参与这些社区可为集成和部署其开源软件的组织带来一系列好处，从教育到支持再到错误修复等等。 + +社区互动不是二元决策。相反，参与是一个连续体。您和您的同事可以选择参与一系列活动中的各种角色，从作为 OSS 消费者的适度开始到持续参与甚至领导。虽然参与水平可以有机地发展，但最好是社区互动水平与组织业务目标保持一致并基于成本效益分析。 + +以下是需要考虑的一些交互级别： + +- 不参与（不推荐） + - 以个人身份参与 +- 不允许与公司有任何联系 +- 代表您的公司参与社区 + - 无 IP 传输 + - 贡献需求或错误修复 + - 传送公司开发的二进制文件、库等。 +- 为社区提供赞助或支持 +- 将公司IP作为OSS发布，建立公司管理的开源项目 + +### 合规 + +合规性侧重于遵守开源政策和开源许可条款。对于分发软件的组织而言，许可证合规性是开源管理中最明显的部分，并且通常为建立开源计划办公室提供动力（在下一课程模块中将详细介绍这一点）。 + +然而，合规性并不是良好治理的“全部”或“全部”——没有人主要为了遵守其许可而使用开源软件。合规性应该与开源管理的其他方面同等对待，而不是作为“警察行动”。 + +对于不分发软件的组织，合规性侧重于确保遵循开源政策和流程，以确保软件系统和应用程序的安全性、可靠性和可支持性。 + +合规政策需要明确和详细，并制定规则以遵守组织政策和开源许可条款。对合规性的需求强调了能够在每个版本中识别和编目第三方代码（包括开源）以及附带条款（例如，源代码披露、归属等）的要求。 + +#### 高管参与 + +开源管理不仅仅是真正接触代码的开发人员的领域。它也不是唯一属于与保护知识产权 (IP) 相关的公司律师的职权范围。成功的开源管理是一项协作努力，需要许多角色和学科的参与。 + +一组经常被忽视的参与者是组织的高管。高管们最初可能认为开源技术仅仅是技术实现的一个细节，并满足于通过指挥链参与开源管理。开明的高管将意识到开源的风险/收益平衡及其创新和差异化的潜力，从而使高管更多地参与围绕开源管理政策的关键决策。 + +对于高管来说，考虑他们在以下政策领域的角色很重要： + +- 参与整体开源政策的创建和演变 +- 参与开源审批 + - 通常通过法律和业务线 +- 参与有关开源贡献、项目赞助等的高层决策 +- 接收和审查关于开源活动的定期报告 + +## 课程：政策实施注意事项 + +### 政策制定中的人为因素 + +与开源相关的政策创建有一些有趣的人类动态，它们不同于传统的 HR 或您的组织可能习惯创建的其他政策。开源的协作和“社区主导”性质更侧重于完成工作，而不是一系列严格或正式的流程。 + +协作是这里的关键要素。与其严格地将这些政策视为惩罚或消除风险的方法，还需要将它们视为不同群体的机会，包括工程师、项目经理、法律专家甚至高管，就如何充分利用这些政策进行透明和坦率的讨论组织参与开源的情况。 + +确实，在某些情况下，管理层可能不得不做出与其他团队（通常是工程部门）并不总是一致的政策决策，但让每个人都可以就政策的创建方式发表意见，这将使每个人都更容易遵守并查看这些政策对组织的意义。 + +### 经济和生产力考虑 + +制定开源政策时要考虑的另一个因素是它们的实施将如何影响工作效率，从而间接影响您的组织的经济影响。 + +构建涵盖所有可能情况并需要大量人力和技术基础设施的完全“防弹”政策似乎是“最安全”的方法，但这些可能会产生意想不到的后果，包括使软件开发变得缓慢、笨拙和令人不快，以至于您运行如果没有这种严格的政策，组织可能会失去关键的软件人才。 + +此外，为此类重量级政策构建必要的流程基础设施在工具和详细的人工监督方面都具有经济成本。对抗构建“完美策略”诱惑的最佳方法是考虑经常重复的开源口头禅“早发 diff --git a/sources/OSPO-101/module2/module2_section3.md b/sources/OSPO-101/module2/module2_section3.md deleted file mode 100644 index c77e3ed..0000000 --- a/sources/OSPO-101/module2/module2_section3.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -status: collected -title: "OSPO 101 Training Modules - Module 2" -author: TODO Group -collector: mudongliang -collected_date: 20240822 -link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md ---- - -# Section: Developing Open Source Policies - -## Lesson: Introduction - -### Section Overview - -In this section, we will discuss how to develop open source policies that set the framework for executing your chosen open source strategy. Special emphasis will be given to key factors that affect the success and organizational adoption of these policies. - -### Learning Objectives - -By the end of this section, you should be able to: - -- Describe the process for implementing open source policies that drive the execution of your chosen strategy - -- Understand what key considerations you need to consider when defining your policies - -- Explain how you can best design policies that encourage widespread adoption in your organization - -- Articulate the role of industry best practices to open source policy development - -## Lesson: Overview of Open Source Policy Areas - -### What Should My Open Source Policy Focus On? - -Organizations starting on their journey of open source sometimes get bogged down in the minutia of defining policies from the perspective of ‘FUD’ (Fear, Uncertainty, and Doubt). While there will be more detailed coverage of areas like open source compliance in future modules, we’d like to give a general overview of the areas that should be considered by all organizations in crafting their open source policies from the perspective of more effective utilization, not just avoidance of risk. - -We’ll also try to address how you can consider both which policies you should focus on first, as well as how to socialize these policies across your organization for maximum effect. - -To do this, we’ll first present the elements that should be in any organizations open source policies - note that this isn’t necessarily an exhaustive list, and there could be additional items depending on your specific business situation: - -- **Discovery** - -- **Review & Approval** - -- **Commercial Procurement** - -- **Code Management & Maintenance** - -- **Community Interaction** - -- **Compliance** - -- **Executive Engagement** - -### Discovery - -Open Source Discovery and Evaluation covers how and where your team finds open source software of interest and by what criteria that software is vetted for inclusion in your organization’s software portfolio. Discovery should not be a hit or miss endeavor. Starting with the right direction and criteria (vs. ad hoc) streamlines this sometimes difficult process and avoids problems down the road. - -Discovering useful open source seldom starts from a blank slate. Most organizations already use at least some open source software and this code can form the basis of an internal (approved) repository. When looking outside the existing portfolio, there is a temptation for engineers to get creative, but to reduce risk and increase efficiency, best practices dictate establishing a set of trusted sources, either through commercial supplier distributions (organizations like Red Hat, Google or others), or through software foundations like Cloud Native Computing Foundation. - -Moreover, a range of community, government and commercial tools exist for finding and choosing appropriate open source project code and versions. For example, OpenHub provides excellent metadata on thousands of popular projects, and Github itself offers dashboard info on project releases. Key security info can be gleaned from the NIST vulnerability database and the open source vulnerability database project. - -It’s important to engage all levels of the organization in developing these discovery policies - simply telling engineers that they cannot use open source except from specific internal repositories without further explanation, and without involving them in the decision process, will likely lead to ‘creative’ attempts to circumvent this policy, which makes compliance harder later on. - -### Review & Approval - -No matter how careful or diligent your discovery process, the real test faced by open source code must come from your review and approval processes. Review and approval are your first lines of defense against security, legal and operational risk that can accompany open source. - -As with discovery, leveraging previously-vetted code can speed up this process, so if your open source team has not already done so, best practices dictate creating lists of approved components and versions, reviewed and approved license types, and previously-employed evaluation rationale and results. - -Building clear criteria (and involving all stakeholders from engineers to program managers) avoids issues during discovery and speeds review. Additionally, it’s important to consider building shortcuts in this policy for low risk approvals that can speed up this process, reduce cost, and provide more incentive for engineering teams to adhere to these policies. - -### Commercial Procurement - -When you first think of discovering and integrating open source code, it’s natural to think primarily of code acquired freely over the Internet. But a substantial amount of open source code makes its way into organizations through commercial sourcing. Open source often accompanies and/or is an integral part of commercial applications and also frequently finds its way into deliverables from contracted development. - -The risks and compliance obligations that accompany commercially-sourced open source are no different from those that come with directly acquired open source. The big difference is that rather than reaching out and downloading open source code directly, your organization receives that code implicitly, even silently, usually through long-standing conventional procurement processes. - -For commercially-sourced open source, industry best practices dictate working with your organization’s supply chain and sourcing personnel to establish and enforce policies for: - -- Reporting the presence of open source elements in 3rd party code - -- IP verification, and where appropriate, indemnification - -- Code scanning and review of supplier governance programs to supplement reporting (if any) - -- Documentation and integration with downstream component tracking, release audit and other compliance activities - -### Code Management & Maintenance - -The concept of "code ownership" emanates from the practices of scores of companies working with open source over the last decade and a half. At the highest level, the practice gives open source code “a face” within your organization, a “go to” person who is close to the code and to the community that develops and maintains it. Also typically included under the code ownership role is coordinating support for that code, directly or through third parties. - -The need for "ownership" arises from the “self-service” nature of open source. Management policy should dictate what type of stewardship these components require and the code owner’s roles and responsibilities. - -Other tasks associated with code management and maintenance are - -- Archiving externally sourced open source - -- Creating a current master copy (including updates, patches, etc.) for internal use, as the basis for sharing and reuse - -- Tracking ownership, approvals and other decisions with an audit trail - -The accompanying support model must be flexible, scalable and sustainable, with low risk and overhead. Options include: - -- Internal support (if resources are available, expertise is strong and risk is low) - -- Commercial support aggregator - -- Focused vendor support for business-critical components and/or platforms for technically complex components or those with high business/technical risk - -### Community Interaction - -Open source software is typically created and maintained by communities of like-minded developers. Participation in those communities confers a range of benefits on organizations that integrate and deploy their open source software, ranging from education to support to bug fixes and beyond. - -Community interaction is not a binary decision. Participation is, instead, a continuum. You and your colleagues can choose to participate in a variety of roles across a range of activities, from a modest start as consumers of OSS up through ongoing involvement and even leadership. While the level of participation can evolve organically, it is always best if the level of community interaction is aligned with organization business goals and based upon a cost-benefit analysis. - -Here are some levels of interaction to consider: - -1. No Participation (not recommended) -2. Participate as individuals - - No tie to company allowed -3. Participate in a community on your company’s behalf - - 1. No IP conveyance - - 2. Contribute requirements or bug fixes - - 3. Convey company-developed binaries, libraries, etc. - -4. Provide sponsorship or support to a community - -5. Release company IP as OSS and establish a company-managed open source project - -### Compliance - -Compliance focuses on observance of open source policy and open source license terms. License compliance is the most visible part of Open Source Management for organizations that distribute software, and often provides the impetus for the establishment of open source program offices (more on this in the next lesson module). - -However, compliance is not the "be all" or ”end all” of good governance – no one uses open source software primarily for the privilege of complying with its licenses. Compliance should be treated on a par with the other dimensions of open source management, and not as a “police action”. - -For organizations that do not distribute software, compliance is focused on ensuring that the open source policy and processes are followed in order to assure the security, reliability and supportability of the software systems and applications. - -Compliance policy needs to be explicit and detailed, with rules spelled out for complying both with organizational policy and with the terms of open source licenses. The need for compliance highlights the requirement to be able to identify and catalogue third-party code (including open source) in each release, together with accompanying terms (e.g., source code disclosure, attribution, etc.). - -### Executive Engagement - -Open Source Management is not solely the province of developers who actually touch the code. Nor is it uniquely under the purview of corporate lawyers concerned with protecting intellectual property (IP). Successful open source management is a collaborative effort, requiring participation from many roles and disciplines. - -One often ignored set of participants is the organization’s executives. Executives may initially think of open source technology as merely a detail of technical implementation, and be content to participate in open source management through the chain of command. Enlightened executives will perceive the risk/benefit balance in open source and its potential for innovation and differentiation, resulting in greater executive participation in key decisions around open source management policy. - -It’s important for executives to consider their role in the following policy areas: - -- Involvement with overall open source policy creation and evolution - -- Participation in open source review and approval - - - Typically through legal and lines of business - -- Participation in high-level decisions about open source contributions, project sponsorship, etc. - -- Receiving and reviewing regular reports on open source activity - -## Lesson: Policy Implementation Considerations - -### Human Factors in Policy Creation - -Policy creation in relation to open source has some interesting human dynamics at play that are different from traditional HR or other policies that your organization might be used to creating. The collaborative and ‘community-led’ nature of open source focuses more on getting work done than it does on a set of rigid or formal processes. - -Collaboration is the key element here. Rather than considering these policies strictly as punitive or ways to eliminate risk, they also need to be considered opportunities for different groups, including engineers, program managers, legal experts, and even executives to have transparent and frank discussions about how to get the most out of the organization’s engagement in open source. - -It’s true that in some cases, management may have to make decisions about policies that aren’t always in agreement with other groups (usually engineering), but in giving everyone a voice in how policies are created, it will make it easier for everyone to comply and see how the policies make sense for the organization. - -### Economic and Productivity Considerations - -Another element to consider when crafting your open source policies is how their implementation will affect working productivity, and therefore, indirectly, the economic impact to your organization. - -Building completely ‘bulletproof’ policies that cover every possible case, and require a massive human and technological infrastructure can seem like the ‘safest’ approach, but those can have unintended consequences, including making software development slow, unwieldy and so unpleasant that you run the risk of losing critical software talent to organizations without such rigid policies. - -Additionally, building out the necessary process infrastructure for such heavyweight policies has economic cost both in tools and in detailed human oversight. The best approach to combat the temptation to build the ‘perfect policies’ is to consider the oft-repeated open source mantra of ‘release early, release often.’ Consider what minimum set of policies you need to implement your open source strategy, and then build on those as both your management team and development organization progress up the ladder of open source engagement. diff --git a/sources/OSPO-101/module2/module2_section4-zh.md b/sources/OSPO-101/module2/module2_section4-zh.md new file mode 100644 index 0000000..9f263f9 --- /dev/null +++ b/sources/OSPO-101/module2/module2_section4-zh.md @@ -0,0 +1,82 @@ +--- +status: translated +title: "OSPO 101 Training Modules - Module 2" +author: TODO Group +collector: mudongliang +collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo +link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md +--- + +# 开源项目办公室介绍 + +## 课程：简介 + +在本节中，我们将讨论开源项目办公室 (OSPO) 在帮助定义战略、实施相关政策和指导组织参与开源方面的作用。 在本系列的后续课程中，将更详细地介绍如何设置和运行 OSPO。 + +## 学习目标 + +在本节结束时，您应该能够： + +- 定义开源项目办公室的特征 +- 解释开源项目办公室在指导组织开源工作中的作用 +- 阐明开源项目办公室可以帮助定义开源成功指标的一些方法 + +## 开源项目办公室 (OSPO) 概述 + +### 什么是 OSPO，为什么我的组织需要它？ + +中央开源项目办公室是一个指定的地方，在公司内部支持、培育、共享、解释和发展开源。有了这样的办公室，企业可以明确地制定和执行他们的开源战略，为他们的领导者、开发人员、营销人员和其他员工提供他们需要的工具，使开源在他们的运营中取得成功。 + +传统软件开发和开源开发之间最大的区别之一是开源中使用的高度协作性。对于许多企业来说，在接近开源使用时所需的理念改变并不容易或自然而然地发生。 + +这就是开源程序的创建可以成为主要福音的地方。通过创建开源项目办公室，企业可以启用、简化和组织开源的使用，使其直接与公司的长期业务计划联系起来。开源项目办公室旨在成为公司开源运营和结构的中心，帮助将所有需要的组件整合在一起。 + +这可以包括设置代码使用、分发、选择、审计和其他政策，以及培训开发人员、确保法律合规性以及促进和建立社区参与。该办公室还可以提供有关公司内外所有开源事物的宣传和交流。 + +### OSPO 的角色 + +归根结底，一个组织良好的开源项目办公室很有价值，因为它可以促进公司内部的开源使用、贡献和创建，以获得战略优势。 + +一个成功的办公室可以通过建立支持开发人员及其团队的流程来极大地受益于企业开源的使用。它鼓励标准编码和组织实践、流程和工具集。同时，项目办公室可以帮助避免或消除不必要的、僵化的流程，创意开发人员可能会规避或忽略这些流程，从而威胁项目的安全性和其他方面。 + +项目办公室的职责各不相同。这些包括： + +- 清楚地传达公司内外的开源战略 +- 拥有并监督战略的执行 +- 促进开源在商业产品和服务中的有效使用 +- 确保向开源社区高质量和频繁地发布代码 +- 与开发者社区互动并看到公司有效地回馈其他项目 +- 在组织内培养开源文化 +- 维护开源许可证合规性审查和监督 + +对于每家公司，开源项目办公室的角色很可能会根据其业务、产品和目标进行自定义配置。没有广泛的模板可以构建适用于所有行业的开源程序，甚至适用于单个行业的所有公司。这可能会使其创建成为一项挑战，但您可以从其他公司中吸取教训，并将它们组合在一起以满足您自己组织的要求。 + +开源项目办公室的另一个关键作用是，当业务部门开始在其计划中考虑开源时，将实质和事实带入对话中，以便充分了解考虑开源的原因、后果和后果。是实现其目标所必需的。这通常是建立对话框架的问题，以便利益相关者在权衡决定时知道从哪里开始以及考虑什么。 + +### OSPO 在定义成功指标中的作用 + +开源项目经理必须证明其工作的投资回报 (ROI)。让我们来看看 OSPO 如何帮助定义组织评估其开源计划、项目和贡献的一些标准方式。 + +学习衡量什么、如何定义成功以及如何最好地利用这些信息来推进您的开源计划目标、证明有效性并获得支持是任何 OSPO 的关键职能。 + +您设定的目标和跟踪的指标将根据您投资开源的原因而有所不同——无论是招募开发人员、通过开放式创新引入新想法和技术、加快上市时间、降低开发成本、或无数其他原因。 + +根据您的独特战略设定目标非常重要——并寻求执行团队的支持，以确保开源战略与整体业务战略保持一致。 OSPO 可以提供一个中立的位置来帮助您的组织战略性地考虑这些项目。 + +有经验的 OSPO 员工在构建指标时通常会考虑以下因素： + +- 他们的开发人员在外部开源项目中的参与度和影响程度 +- 他们的组织在开源社区中的声誉 +- 他们招募和留住有才华的开发人员的能力 +- 组织自己的开源项目及其开发人员参与的关键业务项目的总体健康状况 +- 他们如何管理开源许可证合规性 + +### 关于 OSPO 创建的最终想法 + +构建和运行有效的 OSPO 还有许多其他方面。事实上，我们将在本系列的后续课程模块中有专门的部分和课程。目前，要考虑的最重要的事情是，随着您在开源参与的领导/参与阶梯上继续前进，您最终将需要某种形式的 OSPO。 + +与战略和政策定义一样，重要的是要记住前面引用的“尽早发布，经常发布”的格言。您无需立即为拥有数百人的 OSPO 配备人员即可发挥作用。从具有足够经验来帮助指导您的组织的开源领导者开始，以及可以帮助他们的少量员工，对于大多数组织来说通常是一个足够好的开始。 + +您会自然而然地发现，运作良好的 OSPO 与许多不同的利益相关者（工程、产品管理，甚至高管）互动，尽管规模很小，但它们的效率却成倍增加。我们将在未来的模块中更多地讨论为 OSPO 寻找和建立开源领导力。 \ No newline at end of file diff --git a/sources/OSPO-101/module2/module2_section4.md b/sources/OSPO-101/module2/module2_section4.md deleted file mode 100644 index d1cfa83..0000000 --- a/sources/OSPO-101/module2/module2_section4.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -status: collected -title: "OSPO 101 Training Modules - Module 2" -author: TODO Group -collector: mudongliang -collected_date: 20240822 -link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module2/README.md ---- - -# Section: Introducing the Open Source Program Office - -## Lesson: Introduction - -### Section Overview - -In this section, we will discuss the role that the Open Source Program Office (OSPO) plays in helping define strategy, implementing associated policies, and guiding an organization's involvement in open source. There will be a more detailed coverage of how to set up and run an OSPO in a later module in this series. - -### Learning Objectives - -By the end of this section, you should be able to: - -- Define the characteristics of an Open Source Program office - -- Explain the role of an Open Source Program Office in guiding an organization's open source efforts - -- Articulate some ways an Open Source Program Office can help define metrics for open source success - -## Lesson: Overview of Open Source Program Office (OSPO) - -### What is an OSPO and Why Does My Organization Need One? - -A central open source program office is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their open source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations. - -One of the biggest differences between traditional software development and open source development is the highly collaborative nature used in open source. For many businesses, the needed change in philosophy when approaching open source use doesn’t come easily or naturally. - -That’s where the creation of an open source program can be a major boon. By creating an open source program office, businesses can enable, streamline and organize the use of open source in ways that tie it directly to a company’s long-term business plans. An open source program office is designed to be the center of the universe for a company’s open source operations and structure, helping to bring all the needed components together. - -This can include setting code use, distribution, selection, auditing and other policies, as well as training developers, ensuring legal compliance and promoting and building community engagement. The office can also provide advocacy and communications about all things open source inside and outside the company. - -### The Role of an OSPO - -Ultimately, a well-organized open source program office is valuable because it can advance open source use, contribution, and creation inside companies for strategic advantage. - -A successful office can greatly benefit corporate open source use by establishing processes that enable developers and their teams. It encourages standard coding and organizational practices, processes, and toolsets. At the same time, a program office can help avoid or remove unneeded, rigid processes which creative developers may circumvent or ignore anyway, threatening security and other aspects of projects. - -The responsibilities of a program office are varied. These include: - -- Clearly communicating the open source strategy within and outside the company - -- Owning and overseeing the execution of the strategy - -- Facilitating the effective use of open source in commercial products and services - -- Ensuring high-quality and frequent releases of code to open source communities - -- Engaging with developer communities and seeing that the company contributes back to other projects effectively - -- Fostering an open source culture within an organization - -- Maintaining open source license compliance reviews and oversight - -For every company, the role of the open source program office will likely be custom-configured based on its business, products, and goals. There is no broad template for building an open source program that applies across all industries — or even across all companies in a single industry. That can make its creation a challenge, but you can learn lessons from other companies and bring them together to fit your own organization’s requirements. - -Another key role for the open source program office is to bring substance and facts to the conversation when business units begin to consider open source in their plans so there is a full understanding of why it is being considered, what the consequences will be, and what is needed to reach its goals. It’s often a matter of framing the conversation so that stakeholders know where to start and what to think about as they weigh their decision. - -### The OSPO’s Role in Defining Success Metrics - -Open source program managers must demonstrate the return on investment (ROI) of their efforts. Let’s take a look at how an OSPO helps define some of the standard ways that organizations evaluate their open source programs, projects, and contributions. - -Learning what to measure, how to define success, and how to best use this information to advance your open source program objectives, demonstrate effectiveness, and gain support is a critical function of any OSPO. - -The goals you set, and metrics you track, will vary according to the reasons you’re investing in open source – whether it’s to recruit developers, bring in new ideas and technologies through open innovation, achieve faster time to market, lower development costs, or myriad other reasons. - -It’s important to set goals according to your unique strategy – and seek buy-in from the executive team to ensure that the open source strategy aligns with the overall business strategy. An OSPO can provide that neutral place to help your organization think about these items strategically. - -Experienced OSPO staff generally consider the following when building metrics: - -- Their developers’ participation and level of influence in external open source projects - -- Their organization’s reputation in open source communities - -- Their ability to recruit and retain talented developers - -- The general health of the organization’s own open source projects and the business-critical projects its developers contribute to - -- How well they manage open source license compliance - -### Final Thoughts on OSPO Creation - -There are many other aspects to building and running an effective OSPO. So many, in fact, that we will have a dedicated section and lessons on this in later course modules in this series. For now, the most important thing to consider is that as you continue your journey up the leadership/participation ladder of open source engagement, you’ll eventually need some form of an OSPO. - -As with strategy and policy definition, it’s important to remember the ‘release early, release often’ adage quoted earlier. You don’t need to staff an OSPO with hundreds of people right away to be effective. Starting with an open source leader with enough experience to help guide your organization, and a small staff that can assist them, is usually a good enough start for most organizations. - -What you will find naturally is that well-functioning OSPO’s engage many different stakeholders (engineering, product management, and even executives) in ways that multiply their effectiveness despite their small size. We’ll talk more about finding and building open source leadership for an OSPO in future modules. \ No newline at end of file diff --git a/sources/OSPO-101/module3/README.md b/sources/OSPO-101/module3/README.md index b89dfe8..fea2fef 100644 --- a/sources/OSPO-101/module3/README.md +++ b/sources/OSPO-101/module3/README.md @@ -1,444 +1,411 @@ --- -status: collected +status: translated title: "OSPO 101 Training Modules - Module 3" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module3/README.md --- -# Open Source Program Offices (OSPO) And Your Organization +* 一、介绍 -## Introduction + ## 1.1 课程：简介 -### Section Overview + 在本节中，我们将定义和解释 OSPO 的组成，以及有关该构造在帮助大规模有效管理开源方面的作用和价值的信息。 -In this section, we will provide a definition and explanation of what an OSPO consists of and information on the role and value of this construct in helping effectively manage open source at scale. + ## 1.2 学习目标 -### Learning Objectives + 在本节结束时，您应该能够： -By the end of this section, you should be able to: + - 定义什么是开源项目办公室 (OSPO) + - 解释 OSPO 在您的组织中扮演的角色 + - 阐明 OSPO 为企业带来的价值 -* Define what an Open Source Program Office (OSPO) is -* Explain the role an OSPO plays in your organization -* Articulate the value that an OSPO brings to the enterprise + # 二、课程：定义 -## Definition + ## 2.1 什么是开源项目办公室？ -### What is an Open Source Program Office? + 如上面的介绍性文本中所述，开源计划办公室 (OSPO) 旨在成为贵组织与开源工作的中心纽带。但是，该定义（故意）留下了很大的可变空间。有些人可能会说这会降低价值，但事实上，OSPO 根据不同的组织有不同的定义，这一事实实际上是一种优势，因为它让您可以塑造此结构（并经常更改它）以满足各种需求你可能会在你的开源之旅中。 -As mentioned in the introductory text above, an Open Source Program Office (OSPO) is intended to be the central nexus of your organization’s work with open source. However, that definition leaves (on purpose) a lot of room for variability. Some might say that diminishes the value, but, in fact, the fact that OSPO’s can and do look different depending upon your organization is actually a strength, as it lets you mold this construct (and change it frequently) to address a variety of needs you’ll likely have on your open source journey. + 例如，某些组织的大部分上游开源工作在其 OSPO 中由代表组织工作的特定开发人员进行，以便将产品支持所需的更改纳入开源项目。但是，在某些组织中，这些开发人员分散并嵌入产品开发团队中，并由 OSPO 人员提供建议和培训。 -For example, some organizations centralize the majority of their upstream open source work inside their OSPO, which authorizes specific developers to work on behalf of the organization and propose upstream project changes required for downstream product enablement. However, in some organizations, those developers are decentralized and embedded within product development teams and are advised and trained by OSPO personnel. + 没有“一刀切”的模型，OSPO 可以是任何东西，从拥有大量资源的高度集中到小而分散，依赖于整个组织的资源的影响和培训。可以在 TODO Group 的 github 存储库中的工作中找到有关 OSPO 是什么的很好的概述资源。 -There is no ‘one-size-fits-all’ model, and an OSPO can be anything from highly-centralized with a large set of resources, to small and decentralized, relying on influence and training of resources throughout the organization. A great overview resource for what an OSPO is can be found in the work of the TODO Group in their [github repository](https://github.com/todogroup/ospodefinition.org). + ## 2.2 OSPO在企业中的作用 -### Functions of an OSPO in the Enterprise + 开源项目办公室的主要职能是推动企业内部对开源的消费、贡献和创造，以获得战略优势。 -An open source program office’s main functions are to advance open source consumption, contribution, and creation inside companies for strategic advantage. + 项目办公室的职责各不相同。这些包括： -The responsibilities of a program office are varied. These include: + - 清楚地传达公司内外的开源战略 + - 拥有并监督战略的执行 + - 促进开源在商业产品和服务中的有效使用 + - 确保向开源社区高质量和频繁地发布代码 + - 与开发者社区互动并看到公司有效地回馈其他项目 + - 在组织内培养开源文化 + - 维护开源许可证合规性审查和监督 -* Clearly communicating the open source strategy within and outside the company -* Owning and overseeing the execution of the strategy -* Facilitating the effective use of open source in commercial products and services -* Ensuring high-quality and frequent releases of code to open source communities -* Engaging with developer communities and seeing that the company contributes back to other projects effectively -* Fostering an open source culture within an organization -* Maintaining open source license compliance reviews and oversight + 重要的是要重申，并非所有 OSPO 都具有所有这些功能，或者必须均匀分配他们所从事的工作。项目办公室所做的很大一部分取决于组织的业务需求。 -It’s important here to reiterate that not all OSPOs have all of these functions, or necessarily have even distribution of what things they work on. A large part of what the program office does is dependent on what the organization’s business needs are. + 应该强调的一件事是，OSPO 不仅仅与开发人员合作 - 他们还有许多可以协助的非开发活动，如下所述： -One thing that should be stressed is that OSPOs do more than just work with developers - they have a host of non-development activities that they can assist with, as noted below: + 图片来源：TODO Group OSPO 指南 (https://todogroup.org/guides/) -Credit: TODO Group OSPO Guides ([https://todogroup.org/guides/](https://todogroup.org/guides/)) + ![Image description](./ospo-structure.png) -![OSPO Structure](ospo-structure.png) + ## 2.3 OSPO 的价值 -### The Value of an OSPO + 一个成功的办公室可以通过建立支持开发人员及其团队的政策、流程和指南来极大地受益于企业的开源使用。它鼓励标准编码和组织实践、流程和工具集。同时，项目办公室可以帮助避免或消除不必要的、僵化的流程，创意开发人员可能会规避或忽略这些流程，从而威胁项目的安全性和其他方面。 -A successful office can greatly benefit corporate open source use by establishing policies, processes and guidelines that enable developers and their teams. It encourages standard coding and organizational practices, processes, and toolsets. At the same time, a program office can help avoid or remove unneeded, rigid processes which creative developers may circumvent or ignore anyway, threatening security and other aspects of projects. + 当业务部门开始在其计划中考虑开源时，开源项目办公室会为对话带来实质内容和事实，以便充分了解考虑开源的原因、后果以及实现其目标所需的条件.通过让开源专家帮助构建对话，利益相关者知道从哪里开始以及在权衡他们的决定时要考虑什么。 -An open source program office brings substance and facts to the conversation when business units begin to consider open source in their plans so there is a full understanding of why it is being considered, what the consequences will be, and what is needed to reach its goals. By having specialists in open source help frame the conversation, stakeholders know where to start and what to think about as they weigh their decision. + 计划办公室还充当内部开发人员和开源用户社区之间的重要联络人，以解决和理解出现的问题或要求。项目办公室可以协助解决法律问题，为开发人员提供支持，并为基于公司开源项目的外部用户发声。项目办公室还可以帮助将这些信息传递给公司内部的其他人，包括产品管理团队，以有利于组织的方式进一步推进产品。 -The program office also acts as a critical liaison between internal developers and the open source user communities to resolve and understand issues or requirements that arise. The program office can assist with legal issues, provide developer advocacy, and act as a voice for external users who are building on a company’s open source projects. The program office can also help relay that information to others inside the company, including the product management team, to further advance products in a way that is beneficial to the organization. + # 3. 建立一个有效的开源项目办公室 -# Building an Effective Open Source Program Office + ## 3.1 简介 -## Introduction + 在本节中，我们将展示如何创建一个有效的开源计划办公室，包括有关角色、治理、流程和结构的信息。 -### Section Overview + ## 3.2 学习目标 -In this section, we will show how to create an effective Open Source Program Office, including information on roles, governance, processes and structure. + 在本节结束时，您应该能够： -### Learning Objectives + - 描述形成新 OSPO 的主要步骤 + - 描述可能成为 OSPO 一部分的不同角色和结构 + - 阐明如何将治理和其他流程构建到 OSPO 中 -By the end of this section, you should be able to: + ## 3.3 创建开源项目办公室 -* Describe the main steps in forming a new OSPO -* Describe the different roles and structure that might be part of an OSPO -* Articulate how to build governance and other processes into an OSPO + ### 3.3.1 从哪里开始？ -## Establishing an OSPO + 每家公司都是不同的，在启动 OSPO 时会有不同的需求。该过程可以自上而下开始，并得到高层管理人员的支持；或者自下而上，一小部分开发人员和开源爱好者一直在使用开源并希望看到它正式化。 -### Where to Begin? + 它可以表现为围绕法律问题和安全制定指导的愿望，或者可以从成熟的草根努力开始并吸引企业领导人的注意。它甚至可以从一位有远见的 CEO 或 CTO 开始，他们支持通过深化对开源的承诺来推动公司向前发展并增加价值的事业。 -Every company is different and will have different needs when it comes to starting an OSPO. The process can start from the top down, with buy-in from top management; or from the bottom up, where pockets of developers and open source enthusiasts have been using open source and want to see it formalized. + 这种共识和执行支持对于获得牵引力和推动启动 OSPO 的过程至关重要。您的开源计划办公室之旅的起点对您的组织来说是独一无二的。但是，我们将在接下来的页面中介绍您应该考虑的一些关键步骤。 -It can manifest itself as a desire to create guidance around legal issues and security, or it can start as a grassroots effort that matures and attracts the attention of corporate leaders. It can even start with a forward-thinking CEO or CTO who champions the cause to drive the company forward and add value by deepening its commitment to open source. + ### 3.3.2 寻找领导者 -This kind of consensus and executive support will be essential to gain traction and move the process of starting an OSPO forward. Where you start your open source program office journey will be unique to your organization. However, we’ll cover some critical steps that you should be thinking about in the following pages. + 无论您的计划如何开始，重要的是要找到合适的领导者来帮助开发并在公司内部运行刚刚起步的项目办公室。顶级候选人将对开源的工作原理有详细的了解，以及作为现有开源项目的开发人员、贡献者或提交者工作的一些技术印章。 -### Find a Leader + 他们应该对贵公司的业务以及商业敏锐度和管理技能有广泛的了解，以帮助制定跨业务部门的战略和计划。他们需要善于交际，以便向他人传达热情、知识和信息，并帮助他们了解开源计划将如何为公司带来变革、改变和改进。 -Regardless of how your planning starts, it’s important to find the right leader to help develop and then run the fledgling program office inside a company. The top candidate will have a detailed understanding about how open source works, along with some technical chops from working as a developer, contributor, or committer on existing open source projects. + 项目办公室的负责人需要能够与人们谈论深层技术，但他们不必了解每一项正在发挥作用的技术的来龙去脉，因为他们的主要工作将是帮助制定详细的讨论将发生在多个利益相关者之间。 -They should have a broad understanding of your company’s business along with the business acumen and management skills to help inform strategy and plans across business units. And they need to be sociable so they can convey enthusiasm, knowledge, and information to others and help them understand how the open source initiative is going to transform, change, and improve things for the company. + ### 3.3.3 定义您的操作 -The head of the program office needs to be able to talk with people about the deep technology, but they don’t have to know the ins and outs of every technology at play, because their main job will be to help frame the detailed discussions that will happen among multiple stakeholders. + 新项目办公室所需的预算、人员配备、技术工具和系统也是建立其业务需要解决的关键问题。一些公司从兼职经理开始，但了解到他们只能通过这种方法获得这么多。让某人担任全职工作是启动该计划的坚实一步，同时还有少量支持人员以保持其灵活性。 -### Define Your Operations + 一个定义明确的开源项目办公室的一个例子是推动所需的政策、流程和工具，同时还遵循消除摩擦的咒语，使用工具来自动化可以简化的内容，并委派需要的任务来完成。我们将在以后的部分中详细介绍如何设置策略和流程。 -The budget, staffing, technology tools and systems needed by a new program office are also key issues to resolve in establishing its operations. Some companies begin with a part-time manager, but learn they will only get so far with that approach. Making the position someone’s full-time job is a solid step to get the program off the ground, along with a small support staff to keep it nimble. + 项目办公室必须提供结构化的政策和流程，但也要保持灵活性。当开源用户和贡献者需要帮助时，该办公室更像是一家咨询公司，在提供指导的同时仍允许员工做出与其工作相关的个人或团体业务决策。 -An example of a well-defined open source program office is one that drives needed policy, processes and tools, while also operating with a mantra of eliminating friction where it is found, using tools to automate what can be streamlined, and delegating tasks which need to be accomplished. We’ll cover more specifics on how to set policies and processes in future sections. + ### 3.3.4 寻求反馈和支持 -A program office must offer structured policies and processes but also remain flexible. When open source users and contributors need help, the office operates more like a consultancy, providing guidance while still allowing employees to make individual or group business decisions relating to their work. + 建立开源项目办公室不是凭空而来的事情。因为它将在您的业务中发挥核心作用，所以成功创建它需要企业内部所有相关方公开、诚实的投入和反馈。确保从高管到开发人员的每个人在其创建过程中都有发言权，这将有助于为这项工作提供广泛的支持。 -### Seek Feedback and Buy-in + 了解您的公司正在使用开源做什么，需要从多个利益相关者的角度思考您的组织真正关心的核心问题。尽早寻求此反馈并确保将其反馈到您的 OSPO 部署计划中，这将对项目帮助定义的流程和策略的接受和成功大有帮助。 -Establishing an open source program office isn’t something that should be done in a vacuum. Because it will have a central role in your business, creating it successfully will require open and honest input and feedback from all involved parties inside enterprises. Making sure that everyone from the executives to the developers have a say in its creation will help give the effort broad-based support. + ## 3.4 定义OSPO结构 -Getting a handle on what your company is doing with open source requires thinking from multiple stakeholders about the core things that your organization really cares about. Seeking this feedback early on and making sure it’s fed into your rollout plans for the OSPO will go a long way toward acceptance and success of the processes and strategies the program helps define. + ### 3.4.1 OSPO 应该在哪里？ -## Defining an OSPO Program Structure + 那么开源项目办公室应该如何以及在哪里适合公司的组织结构呢？它应该在工程部门内部吗？还是在法律部门、CTO 办公室或其他特定业务部门？同样，这取决于您公司的主要业务和您的开源战略。 -### Where Should the OSPO Reside? + 让我们在此重申，对于您的 OSPO 应该驻留在何处，并没有“一刀切”的所有答案。在接下来的页面中，我们将讨论一些最常选择的项目办公室位置，但此列表绝不是详尽无遗的。 -So how and where should open source program offices fit inside a company’s organizational structure? Should it be inside the engineering department? Or in the legal department, the CTO’s office or in another specific business unit? Again, that depends on your company’s primary business and your open source strategy. + ### 3.4.2 OSPO 作为法律团体的一部分 -Let’s reiterate here that there isn’t a ‘one-size-fits’ all answer to where your OSPO should reside. In the following pages, we’ll discuss some of the most often chosen locations for the program office, but by no means is this list exhaustive. + 对于拥有大量知识产权组合的公司，这可能意味着开源项目办公室可能非常适合法律办公室，在那里开发人员可以就出现的问题与法律团队密切合作。这可能非常适合硬件公司，因为它总是担心可能会遇到与 IP 相关的法律问题。 -### OSPO as part of a Legal Group + 然而，这种方法的一个挑战是，法律部门下属的 OSPO 最终可能会将他们的大部分时间集中在合规问题上，从而减少了鼓励开源贡献和与外部开源社区联系的其他机会，这些机会可能有益于从长远来看，该组织。如果您决定将您的 OSPO 托管在法律团队中，您将需要一位强大的领导者，他可以在团队角色的合规性方面与与开源社区互动的更具前瞻性和战略性的政策之间取得平衡。 -For companies that have large intellectual property portfolios, that could mean the open source program office might be a perfect fit in the legal office, where developers can work closely with the legal team on issues that arise. That might be a good fit for a hardware company because it’s always concerned about potentially running into IP-related legal issues. + ### 3.4.3 工程中的 OSPO -One challenge with this approach however, is that an OSPO under the legal department could end up focusing a significant portion of their time on compliance matters, thereby diminishing other opportunities to encourage open source contributions and outreach to external open source communities that can be beneficial to the organization in the long term. If you decide to host your OSPO in the legal group, you’ll need a strong leader who can balance the compliance aspects of the group's role with more forward-thinking and strategic policies on engaging with the open source community. + 更受工程驱动的公司通常选择在其工程部门内维护其开源项目办公室。这使他们能够直接将精力集中在使开发人员在工作中更加有效和高效。 -### OSPO in Engineering + 在许多情况下，这些计划办公室向 CTO 或在某些情况下向 CIO 报告。在拥有强大/关联产品集的组织中，办公室可以向产品开发副总裁或工程副总裁报告。在拥有不同产品组合的公司中，通常最好将 OSPO 安置在 CTO 办公室内，因为这使其在帮助所有工程团队制定政策和教育工作方面拥有最广泛的视野和自由度。 -Companies who are more engineering-driven often choose to maintain their open source program offices within their engineering departments. That allows them to focus their efforts directly on making their developers more effective and productive in their work. + 这种方法的一个缺点可能是不太关注合规活动（与与法律小组一起主持 OSPO 相比），但同样，强大的领导者可以在这里提供必要的平衡，如果做得好，它如果开发人员认为流程轻量级且不繁重，则可以提高开发人员的合规性。 -In many cases, these program offices report into the CTO or in some cases the CIO. In organizations with a strong/connected set of products, the office can report to the VP of Product Development or VP of engineering. In companies with disparate product portfolios, it’s usually best to house the OSPO within the office of the CTO, as this gives it the widest view and latitude in helping develop policies and education efforts for all of the engineering teams. + ### 3.4.4 OSPO 作为开发者关系/营销的一部分 -One downside to this approach can potentially be less of a focus on compliance activities (as compared to hosting the OSPO with the legal group), but again, a strong leader can provide the necessary balance here, and, if this is done well, it can lead to increase compliance by developers if they feel that the processes are lightweight and not onerous. + 对于某些组织，开源办公室位于营销组内部，因为他们使用开源来汇集潜在客户，旨在销售他们使用开源构建的产品。如果一个组织需要与关键的开源开发人员和项目建立密切的联系，那么将 OSPO 托管在像开发人员关系这样的小组中可以提供这种支持。 -### OSPO as part of Developer Relations/Marketing + 当然，OSPO 仍然必须能够根据需要在合规性和教育领域中执行其他所需的角色。 -For some organizations, open source offices are located inside the marketing group because they use open source to funnel leads aimed at selling the products they build using open source. If an organization requires a close connection with key open source developers and projects, hosting the OSPO in a group like developer relations can provide this support. + ### 3.4.5 实施注意事项 -Of course, the OSPO still has to be able to perform other needed roles in the compliance and education domains as necessary. + 在决定将您的 OSPO 放置在组织中的位置时，另一个需要考虑的重要因素是您计划采用集中式还是分散式方法。 -### Implementation Considerations + 在较小的组织中，拥有一个集中的开源程序办公室，将所有用于消费、协作和创建的工作流都集中在一个中心位置可能会很好地工作。它确保方法和合规性的最大一致性，但随着组织的发展，它也可能变得笨拙。 -Another important element to consider when making the decision about where to place your OSPO in the organization revolves around whether you are planning a centralized vs. decentralized approach. + 中心化组织有时也会接待主要开发人员，他们将代表组织为上游开源项目做出贡献。这些开发人员通常充当产品团队的内部顾问，他们可能缺乏培训和专业知识，无法独自为开源项目做出贡献。 -In a smaller organization, having a centralized open source program office with all workflows for consumption, collaboration and creation coming to a central location might work well. It ensures the greatest consistency of approach and compliance, but as an organization grows, it can also become unwieldy. + 但是，一旦您的组织变得足够大，分散的方法通常效果最好，因为您可以专注于教育和为开发人员和管理人员提供咨询资源，以做出与整体组织政策一致的关于开源的产品特定决策。这种方法还可以在整个组织中传播开源知识，并有助于培养更加开放和协作的文化，这是与更大的开源生态系统合作的重要特征。 -Centralized organizations sometimes also host the main developers who will contribute to upstream open source projects on behalf of the organization. These developers often act as internal consultants for product teams who may lack the training and expertise to contribute to open source projects on their own. + 在本模块的后面部分，我们将分享案例研究，以举例说明其他组织如何做出这些结构性决策。 -Once your organization becomes large enough though, a decentralized approach generally works best, as you can focus on educating and providing consulting resources for developers and managers to make product-specific decisions about open source that are consistent with the overall organizational policies. This approach also spreads the open source knowledge throughout your organization and helps foster a more open and collaborative culture, which is an important trait for working with the larger open source ecosystem. + ## 3.5 OSPO角色 -In a later section of this module, we’ll share case studies to give some examples of how other organizations have made these structural decisions. + 在创建开源项目办公室时，必须确定开源项目经理、公司法律团队以及任何由工程师和高管组成的审查委员会的角色和职责。此外，随着 OSPO 的发展，可能会有其他角色为组织提供价值。在接下来的几页中，我们将更详细地介绍这些角色。 -## Lesson: OSPO Roles + ### 3.5.1 项目经理 -### Management Roles + 为了获得最大的效率，项目经理应该被授权为行政级别的职位，直接监督和亲自管理公司在开源活动中的利益。这将为他们提供所需的工具，以引领企业内部朝着其开源目标和愿景迈进。 -In creating an open source program office, decisions must be made to establish the roles and responsibilities of the open source program manager, the company’s legal team, and any review board made up of engineers and executives. Additionally, as an OSPO grows, there may be additional roles that provide value to the organization. In the next few pages we’ll cover these roles in more detail. + 一些公司选择使用类似于审查委员会的开源执行委员会。这样的小组通常由公司内部所有主要业务部门的高层领导组成，对政策变化和引入提供董事会式的指导，为开源计划设定优先级，并协助推动组织行为的变化。 -#### Program Manager + ### 3.5.2 法律 -For maximum effectiveness, the program manager should be empowered as an executive-level position with direct oversight and hands-on management of the company’s interests in its open source activities. That would give them the tools they need to lead the way inside an enterprise toward its open source goals and vision. + 与公司内部的所有其他职能一样，法律团队必须在开源项目办公室的运营中拥有发言权，以确保遵守法律、开源许可协议和其他法律细节。具体到开源，法律团队需要负责确保公司可以在内部使用代码并以可接受的条件回馈项目。 -Some companies choose to use an Open Source Executive Council, which is similar to a review board. Such a group is usually made up of senior leaders from all major business units inside the company, and provides board of directors-style guidance on policy changes and introductions, sets priorities for the open source program, and assists in driving changes in organizational behavior. + 较大的组织应考虑聘请或培训专职律师为其开源计划提供建议。但您也可以聘请兼职、知识渊博的工作人员或外部法律顾问。与在开源许可和知识产权方面知识渊博且经验丰富的律师合作通常很有帮助，因为它可能是与商业合同或标准相关的专门的、有时令人困惑的法律领域。 -#### Legal + ### 3.5.3 合规团队 -Like every other function inside a company, legal teams must have a say in the operations of the open source program office to ensure compliance with laws, open source licensing agreements, and other legal details. Specific to open source, the legal team needs to be responsible for ensuring that a company can consume code internally and contribute back to projects with acceptable terms. + 开源合规团队是一个跨学科的团队，由负责确保开源许可合规性的不同个人组成。核心团队，通常称为开源审查委员会 (OSRB)，由工程和产品团队的代表、一名或多名法律顾问以及合规官（通常是开源项目经理）组成。 -Larger organizations should consider hiring or training a dedicated attorney to advise their open source program. But you could also use a part-time, knowledgeable staff member or outside counsel. It is often helpful to work with an attorney who is knowledgeable and experienced with open source licensing and IP as it can be a specialized, and at times baffling, legal domain relative to commercial contracts or standards. + 扩展团队由多个部门的不同人员组成，他们持续为合规工作做出贡献。这些可能包括文档、供应链、企业发展、IT、本地化和开源执行委员会 (OSEC)。但是，与核心团队不同的是，扩展团队的成员仅根据他们从 OSRB 收到的任务，兼职从事合规工作。 -#### Compliance Team + ### 3.5.4 开发者关系、宣传和布道者 -The open source compliance team is a cross-disciplinary group consisting of various individuals tasked with the mission of ensuring open source license compliance. The core team, often called the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and the compliance officer (who is often the open source program manager). + 开源开发人员关系和布道者对于刚刚起步的开源项目办公室很重要，因为他们可以在公司的开发人员社区中为特定项目建立兴趣和热情，这有助于增加工作量并增加工程师之间的团队合作。布道者经常参加会议和技术活动并解释什么是开源，以帮助观众了解如何使用它以及它提供哪些挑战和机遇，同时与开源社区分享他们的企业经验。 -The extended team consists of various individuals across multiple departments that contribute on an ongoing basis to the compliance efforts. These may include documentation, supply chain, corporate development, IT, localization and an Open Source Executive Committee (OSEC). However, unlike the core team, members of the extended team only work on compliance on a part-time basis, based on tasks they receive from the OSRB. + ### 3.5.5 其他 -#### Developer Relations, Advocacy, and Evangelists + 此外，创建其他工作角色对于开源项目办公室的成功也很重要，包括工具管理员、培训经理、工具和系统的集成开发人员、部署支持人员和实施项目负责人。例如，工具管理员需要帮助为从事开源项目的工程师选择、提供和集成所需的工具，同时还要确保这些工具满足企业的许可和其他要求。 -Open source developer relations and evangelists can be important to a fledgling open source program office because they can work to build interest and enthusiasm within a company’s developer community for specific projects, which can help grow the efforts and increase teamwork among engineers. Evangelists often go to conferences and tech events and explain what open source is to help audiences understand how it can be used and what challenges and opportunities it offers, while sharing their corporate experiences with the open source community. + ### 3.6 定义OSPO流程 -#### Others + ### 3.5.1 概述 -In addition, the creation of other job roles is important for the success of the open source program office, including tool administrators, training managers, integration developers for tools and systems, deployment support staffers, and implementation project leads. Tool administrators, for example, are needed to help select, provide and integrate needed tools for engineers working on their open source projects, while also ensuring the tools meet the licensing and other requirements of an enterprise. + 在解决 OSPO 的结构和人员配备要求后，下一步是制定明确定义的政策和流程，这将使贵公司的开源战略得以一致实施。 -## Defining OSPO Processes + 这些政策应列出在整个公司范围内使用开源的要求和规则，以及记录和可执行的流程，以确保这些规则在日常基础上得到遵守。 -### Overview + 至关重要的是，这些流程应该需要最少的开销，并在审查现有开源政策和流程时努力反复消除、自动化和委派，以便不断质疑和更新规则以简化程序。这意味着要问为什么政策甚至到位以及如何为用户改进它们。 -After tackling an OSPO’s structure and staffing requirements, the next step is to develop well-defined policies and processes which will enable consistent implementation of your company’s open source strategy. + 即使这些规则是为开源项目办公室精心制定的，公司也必须准备好随着时间的推移，随着业务的变化以及开源项目的成熟和发展，根据需要发展和修改规则和程序。 -The policies should lay out the requirements and rules for working with open source across the company, as well as documented and executable processes which will ensure the rules are followed on a day-to-day basis. + ### 3.6.2 要问的问题 -Crucially, these processes should require minimal overhead and strive to repeatedly eliminate, automate and delegate when reviewing existing open source policies and processes so the rules are constantly questioned and updated to streamline procedures. That means asking why policies are even in place and how they can be improved for users. + 在起草开源政策和流程时，需要讨论的许多主题包括： -Even as those rules are carefully created for open source program offices, companies must be prepared to evolve and modify the rules and procedures as needed over time as their businesses change and as their open source engagements mature and grow. + - 贵公司的员工如何为开源项目做出贡献 + - 贵公司如何开源内部项目 + - 贵公司如何接受外部对其开源项目的贡献 + - 如何准备开源版本 + - 如何获得批准 + - 开发人员如何使用他们在 GitHub 和其他代码存储库中找到的开源代码 + - 解释如何将开源代码引入贵公司的程序和规则 + - 如何对传入的代码进行编目，以便其他人知道它正在被使用 + - 公司如何围绕其发展志同道合的外部开发人员社区以保持其蓬勃发展 + - 有助于确定代码何时应作为开源发布或作为知识产权保留的规则 -### Questions to Ask + 这些问题的答案有助于为未来的政策和流程提供信息 - 我们将在以下页面中介绍这些政策的一些示例。 -When drafting open source policies & processes, among the many topics that need to be discussed are: + ### 3.6.3 代码发布政策 -* How employees of your company can contribute to open source projects -* How your company can open source internal projects -* How your company accepts external contributions to their open source projects -* How to prepare for open source releases -* How approvals are received -* How developers can use open source code they find on GitHub and other code repositories -* Procedures and rules explaining how open source code can be brought into your company -* How the incoming code is catalogued so others know it is being used -* How a company can grow a community of like-minded external developers around it to keep it thriving -* Rules that help determine when code should be released as open source or kept as intellectual property + OSPO 的一个重要目标是帮助开发人员成功地为开源项目做出贡献并发布他们自己的项目。指南和清单确保开发人员拥有将代码作为开源发布所需的一切，而不会遇到许可或保密问题。特别是对于新的贡献者，在做出贡献之前，将内部审查过程作为一个安全的地方来获得反馈也很有帮助。 -The answers to these questions help inform policies and processes going forward - we’ll cover some examples of these policies in the following pages. + 您的组织还应努力采用“上游优先”的发展政策。通过首先向上游开源项目提交补丁，然后将它们合并到您下游自己的产品中，您将避免在每次发布后花费大量时间和金钱进行重新设计。 -### Policies for Releasing Code + ### 3.6.4 接受捐款的政策 -An important OSPO goal is to help developers be successful in making contributions to open source projects and in releasing their own projects. Guidelines and checklists ensure that developers have everything they need to release their code as open source without running into licensing or confidentiality issues. Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution. + 如果您最终创建了自己的开源项目并且它们不是托管在一个中立的基金会，您将需要为您的公司创建程序以接收外部开发人员对这些项目的贡献。 -Your organization should also strive to adopt an "upstream first" development policy. By submitting patches to the upstream open source project first, and incorporating them into your own products downstream, you will avoid spending a massive amount of time and money on re-engineering after each release. + 当然，这是将您公司的开源代码发布到其他社区并邀请其他开发人员对您自己的项目产生兴趣的好处之一。因为在宏伟的计划中，即使他们不是您的正式员工，您也可以让来自世界各地的优秀人才为您公司的代码工作，使其变得更好并扩展其能力。这种协作对公司很重要，也是许多开源项目办公室的共同关注点。 -### Policies for Accepting Contributions + ### 3.6.5 促进采用的政策 -If you eventually create your own open source projects and they are not hosted at a neutral foundation, you’ll want to create procedures for your company to receive contributions to these projects from external developers. + 您还想鼓励其他人在他们的产品和服务中使用您的代码。这是构建生态系统的关键，而生态系统反过来又有助于发展和维持您的开源项目。开源使用政策可以有多种创新形式。 -That is, of course, one of the benefits of putting your company’s open source code out into other communities and inviting other developers to establish an interest in your own projects. Because in the grand scheme of things, even though they are not officially your employees, you can have brilliant people working on your company’s code from around the world, making it better and expanding its capabilities. This kind of collaboration is important for companies and is a common focus for many open source program offices. + 例如，Red Hat 有一个独特的政策，在大多数情况下，从一开始就默认将其新创建的代码开源。这意味着在公司内部开发每一款软件时，都假设未来它可能注定要作为开源发布。 -### Policies to Promote Adoption + 由于这种审查，开发人员在编写开源代码时倾向于以更好的方式构建事物，从而在他们的工作中创建具有更少或改进的代码依赖性的更清晰的代码。 -You also want to encourage others to use your code in their products and services. This is key to building ecosystems that in turn help grow and sustain your open source projects. Policies for open source use can come in a variety of innovative forms. + ### 3.6.6 内部消费政策 -For example, Red Hat has a unique policy by defaulting to open source with its newly-created code in most cases from the start. That means that when developing each piece of software inside the company, it is assumed that in the future it may be destined to be released as open source. + 其他需要的政策包括关于您的团队如何以及在何处为开源软件的使用和创建找到可信来源的规则、关于建立代码管理和维护程序的政策，以及为您的项目正规化社区互动的政策。 -Due to that scrutiny, developers tend to structure things in better ways when writing open source, creating cleaner code with fewer or improved code dependencies in their work. + 开源使用政策确保进入产品库的任何软件（专有、第三方或开源）都经过审核、审查和批准。它还确保您的公司在您的产品之前有一个计划来履行因使用各种软件组件而产生的许可义务。 -### Policies for Internal Consumption + # 4 附加信息和案例研究 -Other needed policies include rules about how and where your team finds trusted sources for open source software use and creation, policies about establishing code management and maintenance procedures, and formalizing community interaction for your projects. + ## 4.1 简介 -An open source usage policy ensures that any software (proprietary, third-party, or open source) that makes its way into the product base has been audited, reviewed, and approved. It also ensures that your company has a plan to fulfill the license obligations resulting from using the various software components, before your products make it to customers. + 在本节中，我们将提供一些已建立开源计划办公室的组织的案例研究，并提供一些指向其他信息的提示，这些信息将帮助您开始创建 OSPO 以实现更有效的开源计划管理。 -For example, your policy could require engineers to receive approval from your organization’s auditing staff, such as an open source review board (OSRB), before integrating any open source code in a product. It may also state that software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships. + ## 4.2 学习目标 -### Policies for License Compliance + 在本节结束时，您应该能够： -Also needed are policies to formalize and establish legal compliance procedures and to assure executive oversight for the program. + - 描述几个开源程序办公室实现之间的主要区别 + - 知道去哪里获取有关构建您自己的 OSPO 的其他信息 -You’ll also want to map out how you’ll handle the software tools that will make much of the compliance and code testing work possible by automating it and streamlining procedures for developers and contributors. More details on compliance tools will be covered in later course modules in this series. + ## 4.3 案例研究 -Existing open source resources are also potential gold mines for finding other materials needed by your open source projects, including documentation for contributor license agreements (CLAs). CLAs are used to "define the terms under which intellectual property has been contributed to a company/project", typically software under an open source license. Projects that use CLAs require contributors, and often their companies, to sign the CLA before contributions will be accepted by the project. Determining your company's policies on using and signing CLAs is an important step to consider in building your overall license compliance policy. + ### 4.3.1 概述 -### Final Words + 如前所述，每个组织的开源项目办公室可能都不同。 这反映了不同商业模式的现实以及每个组织当前的开源成熟度和意识状态。 -There’s a lot of work to do and much to consider when your company decides to create an open source program office, but its value will likely outweigh the efforts taken to accomplish it. Finding just the right leader to drive the program office initiative is a critical step in the process to make it a success. + 为了给出一个相当广泛的视角，我们选择了三家公司及其 OSPO 创建历程作为案例研究。 这些组织慷慨地捐赠了他们的开源领导者和管理团队的时间来构建这些案例研究，希望它们对开始开源之旅的其他人有用。 -It’s also important to remember that the heart of the OSPO is really a culture change endeavor. Obviously software plays a key role, but understanding your company’s current culture, and where you want to go in open source is critically important. For all of the process and education pieces of an OSPO, the biggest realization that most organizations make is that this program, and it’s leader are really change agents within the organization. + 我们的案例研究来自： -# Additional Information & Case Studies + - 康卡斯特 + - 微软 + - Salesforce -## Introduction + 在这些研究中，您将看到不同的工具、组织甚至指标方法。 这些研究是在 TODO 组（Linux 基金会倡议）的支持下进行的，我们将在本模块后面提供指向其他信息的指针。 -### Section Overview + ### 4.3.2 康卡斯特 -In this section, we will provide some case studies of organizations that have built Open Source Program Offices, as well as give some pointers to additional information that will help you as you begin the journey to creating your OSPO for more effective open source program management. + 康卡斯特对开源的参与是一个逐渐演变的过程。该公司最终创建了两个开源项目办公室，一个用于 NBC 业务，另一个用于业务的有线电视方面，这是本简介的主题。 -### Learning Objectives + Comcast 于 2006 年左右开始为开源做出贡献，当时首席软件架构师 Jon Moore 为 Apache HTTP 做出了补丁贡献。他向管理团队展示了将补丁整合到主项目中比单独维护它更具成本效益。 -By the end of this section, you should be able to: + 摩尔与跨学科团队合作，成立了一个开源咨询委员会，该委员会由法律和技术主题专家组成。他们审查了贡献并创建了专注于良好开源实践和社区建设的内部指南。 2013 年，当他们开始跟踪这些贡献时，他们有 13 个。今年，他们计划将其增加近 10 倍。 -* Describe the main differences between several open source program office implementations -* Know where to go for additional information on building your own OSPO + “当公司建立开源实践时，他们发出了一个重要信息，即我们对开源是认真的，我们想投资它。” – Nithya Ruff，康卡斯特开源实践高级总监。 -## Case Studies + **开源程序实践的六个 C** -### Overview + 2016 年，康卡斯特聘请 Ruff 领导一项日益重要的开源战略。 这种做法得到了康卡斯特领导团队最高层的支持，他们想要一个能够提出问题、教育员工并提高意识的组织。 -As was mentioned earlier, every organization’s Open Source Program Office is likely to be different. This reflects the realities both of differing business models as well as each organization’s current state of open source maturity and awareness. + 开源项目实践有 3 名全职人员（截至 2020 年 6 月），同时依靠法律、工程、IT、公关等领域的功能专家来帮助扩展项目。 目标是指导、指导、建议、推荐和作为员工的顾问。 Ruff 用“六个 C”总结了开源实践的功能：消费、贡献、合规、沟通、协作和能力建设。 -In order to give a reasonably broad perspective, we’ve picked three companies and their OSPO creation journeys as case studies. These organizations have graciously donated the time of their open source leaders and management teams to build these case studies in the hopes that they will be of use to others who are starting their journey in open source. + ![Image description](./comcast-ospo.png) -Our case studies are from: + 开源实践有两个主要目标。 -* **Comcast** -* **Microsoft** -* **Salesforce** + - 让公司内部的人更容易在开源中工作。 无论是对开源的消费、对开源的贡献，还是与社区、基金会和组织的合作，目标都是消除法律、流程、工具、沟通和意识障碍。 + - 在开源和技术社区中对外可见。 许多人不知道 Comcast 是一家拥有数千名开发人员的技术公司，因此他们想提高认识并分享他们正在做的事情。 -In these studies, you’ll see different approaches to tooling, organization and even metrics. These studies were conducted under the auspices of the TODO Group (a Linux Foundation Initiative) and we will have pointers to additional information later on in this module. + **开源贡献** -### Comcast + 除了对现有的开源社区（如 OpenStack）做出重大贡献之外，康卡斯特还开源了一些项目。 Apache Traffic Control 是在 Comcast 内部启动的，并已贡献给了目前正在孵化的 Apache 软件基金会。 -Comcast’s involvement in open source was a gradual process that evolved over time. The company eventually created two open source program offices, one for the NBC business and another for the cable side of the business, which is the subject of this profile. + 他们还在建立一个名为 RDK 管理项目的独立财团方面发挥了重要作用，该财团专注于围绕机顶盒创建标准。 RDK 软件使用 Yocto 构建系统来创建一个一致的层，这样从半导体供应商到 OEM 和 ISV 的每个人都可以使用一致的系统和结构来构建机顶盒和类似设备的内容。 -Comcast began contributing to open source around 2006 when Jon Moore, Chief Software Architect, made a patch contribution to Apache HTTP. He showed the management team that it was more cost effective to have the patch incorporated into the main project than it was to maintain it separately. + 康卡斯特开源了它的 Speed-TestJS 工具，这是一个测试互联网速度的工具，因为该公司希望在他们如何测量速度方面对世界保持透明。该项目还允许人们自己使用该工具，以确保他们认为康卡斯特正在兑现承诺。这是一个很好的工具示例，它可以通过开放来创建更多信任。 -Working with an interdisciplinary team, Moore worked to set up an open source advisory council, which consisted of legal and technical subject matter experts. They reviewed contributions and created internal guidelines focused on good open source practices and community building. In 2013, when they started tracking these contributions, they had 13. They had plans to do almost 10x more of that in 2017. + 除了为项目做出贡献外，康卡斯特还是多个基金会的成员，包括 Cloud Foundry 基金会、Apache 软件基金会、Linux 基金会、Yocto 项目、Linaro、OpenStack 基金会、开放网络自动化平台 (ONAP) 和 OpenDaylight。 -*"When companies establish open source practices they send a big message saying that we’re serious about open source and that we want to invest in it."* – Nithya Ruff, Senior Director Open Source Practice at Comcast. + ![Image description](./oss-foundations.png) -#### Six C’s of Open Source Program Practice + 通过这些贡献，康卡斯特已经从参与开源社区的善意中受益。康卡斯特的贡献还帮助该公司招募了新的开发人员。今天的开发人员希望为那些优秀的开源企业工作，而康卡斯特在各个社区的贡献表明，他们对开源的承诺是认真的。 -In 2016, Comcast hired Ruff to lead an increasingly vital open source strategy. The practice has support from the highest levels of the Comcast leadership team who wanted an organization that would field questions, educate employees, and create awareness. + **与业务保持一致** -The open source program practice has three full-time people (as of June 2020) while relying on functional experts in legal, engineering, IT, PR, and more to help scale the programs. The goal is to coach, guide, advise, recommend, and serve as a consultant to employees. Ruff summarizes the function of an open source practice with "the six C’s": consumption, contribution, compliance, communication, collaboration, and competency-building. + “作为一家公司，实践的建立、基金会层面的可见参与、增加的贡献、领导支持和工具支持使开源变得容易。” – Nithya Ruff，康卡斯特开源实践高级总监。 -![Comcast OSPO](comcast-ospo.png) + 确保贵公司的开源战略与其业务战略紧密结合非常重要。 开源办公室应该真正了解公司的目标，并在开源战略中启用它们。 这种战略一致性允许开源实践与康卡斯特更广泛的公司目标保持一致，以鼓励实践和整个公司的长期成功。 -The open source practice has two main goals. + ### 4.3.2 微软 -1. Make it easier for people inside the company to work in open source. Whether it’s consumption of open source, contribution to open source, or collaboration with communities, foundations, and organizations, the goal is to remove legal, process, tool, communication, and awareness barriers. + 微软现在是开源领域公认的大玩家，但就在几年前，对于这家软件巨头来说，这样的角色似乎是不可想象的。 因此，当微软从其市场领先地位中脱颖而出，成为专有软件制造商，大举迈向开源时，许多人感到惊讶。 尽管该公司的故事令人瞩目，但它的开源之旅并不像看起来那么突然或出乎意料。 -2. Be visible externally in open source and technology communities. Many people don’t know that Comcast is a technology company with thousands of developers so they want to raise awareness and share what they’re doing. + “尽管有这样的看法，微软已经做了很长一段时间的开源。起初，它到处都是实验性的作品，但大约六年前，在 2011 年，我们将其中的大部分内容集中在一个名为 Microsoft Open Technologies 的实体中，” 微软开源项目办公室主任 Jeff McAffer 解释道。 -#### Open Source Contributions + **真诚的开源** -Comcast has [open sourced a few projects](https://github.com/Comcast) in addition to contributing significantly to existing open source communities, like OpenStack. [Apache Traffic Control](https://trafficcontrol.incubator.apache.org/) was started within Comcast and has been contributed to the Apache Software Foundation where it is currently in incubation. + McAffer说，这就是微软开始认真探索如何利用开源技术的时候。在早期，如果公司中有人对使用开放源码做任何事情感兴趣，他们就会到集中的小组寻求相关开放源码开发人员、贡献者和维护人员的帮助。 -They were also instrumental in setting up an independent consortium called the [RDK Management Project](http://rdkcentral.com/) focused on creating a standard around set-top boxes. The RDK software uses the Yocto build system to create a consistent layer such that everyone from the semiconductor vendors right up the chain to OEMs and ISVs can use a consistent system and structure to build the content for set-top boxes and similar devices. + 大约三年前，情况开始发生变化。微软决定让开源在整个公司普及，并在主要的工程团队中推行开源。 -Comcast open sourced its [Speed-TestJS tool](https://github.com/Comcast/Speed-testJS) , which is a test of internet speed, because the company wanted to be transparent to the world in terms of how they measure speed. The project also allows people to use the tool themselves to make sure that they felt that Comcast was delivering what it promised. This is a great example of a tool that could create more trust as a result of being open. + “如果这就是我们所做的一切，我们就会在如何进行开源方面留下一个难以维持的真空，”McAffer说。“有人必须考虑政策，以及如何协调所有的开源努力，他们将使用的过程和工具，我们如何跟踪项目，等等。所以，我们创建了现在的开源项目办公室来处理所有这些问题。” -In addition to contributing to projects, Comcast is also a member of a number of foundations, including [Cloud Foundry Foundation](https://www.cloudfoundry.org/membership/) , the [Apache Software Foundation](https://www.apache.org/) , [The Linux Foundation](https://www.linuxfoundation.org/membership/) , [Yocto Project](https://www.yoctoproject.org/) , [Linaro](https://www.linaro.org/) , [OpenStack Foundation](https://www.openstack.org/foundation/) , [Open Network Automation Platform (ONAP)](https://www.onap.org/) , and [OpenDaylight](https://www.opendaylight.org/) . + 一些来自早期开源小组的技术人员搬到了新成立的项目办公室，而其他人则加入了与他们的工作相关的工程小组。事实证明，微软需要额外的人才，以确保所有项目和流程都得到充分的人手，因此，招聘工作，无论是内部还是外部，很快就开始了。今天，开源是微软全球工作中一个蓬勃发展的部分。 -![Comcast OSPO External Collaborations](oss-foundations.png) + **业务和规划目标** -Through these contributions, Comcast has benefited from the goodwill that comes from participating in open source communities. Comcast’s contributions have also helped the company recruit new developers. Developers today want to work for companies that are good open source citizens, and Comcast’s contributions in a variety of communities demonstrate that they are serious about their commitment to open source. + 微软没有一个中央的开源战略，也没有一个中央的批准机构。相反，开源程序办公室促进了整个公司的讨论和决定。团队仍然需要对他们的开源项目进行评审，但更多的是在本地进行。 -#### Aligning with the Business + McAffer说:“他们了解自己的业务，他们知道他们希望如何让技术交互起作用，他们希望在生态系统方面推动什么，以及所有需要发生的各种细微差别。” -> "The establishment of the practice, visible engagement at the foundation level, increased contributions, leadership support, and tooling support as a company have made it easy to do open source." – Nithya Ruff, Senior Director Open Source Practice at Comcast. + “我们将大部分决策和方向交由当地管理层，但我们给他们一个架构，让他们思考这些决策和方向。我们有关于如何管理IP和如何处理安全问题的核心政策。我们为他们提供体现这些政策的工具和流程，让他们以连贯而具体的方式执行这些政策变得超级简单。” -It’s important to make sure that your company’s open source strategies are closely aligned with its business strategy. The open source office should really understand the goals of the company and enable them in the open source strategy. This strategic alignment allows the open source practice to remain aligned with the broader company goals at Comcast to encourage long-term success for the practice and the company as a whole. + **管理工具** -### Microsoft + Microsoft 的政策归结为流程，然后相应地使用工具来处理工作负载。一个例子是开源版本。根据政策，在 GitHub 上发布。 -Microsoft is now an accepted big player in the open source space, but just a few years ago such a role for the software giant, seemed inconceivable. Many people were thus surprised when Microsoft emerged from its market lead as a proprietary software maker to make a move towards open source in a big way. Although the company’s story is remarkable, its open source journey has been neither as abrupt or unexpected as it may have appeared. + “我们在 GitHub 上拥有大量工具，我们在 GitHub 上管理着大约 100 个组织的 10,000 多个存储库，大约有 12,000 名微软员工在该领域进行交互，”McAffer 说。 -> "Despite perception, Microsoft has been doing open source for quite a while. At first, it was experimental pieces here and there but about six years ago, in 2011, we brought much of that into focus in an entity called Microsoft Open Technologies," explained Jeff McAffer, Director of Open Source Programs Office at Microsoft. + “这达到了一个规模，你真的需要一个系统来管理多个方面。例如，当人们想要为我们正在运行的项目之一做出贡献时，我们需要工具来帮助管理贡献者许可协议或CLA。对于所有这些事情，我们要么自己构建解决方案，要么转向开源解决方案。”例如，对于 CLA 管理，Microsoft 使用 CLA Assistant，这是 SAP 发起的开源程序。 -#### Open Source in Earnest + “在 GitHub 管理方面，我们走向了另一个方向，因为没有一套现有的工具来帮助管理 GitHub 上的企业存在，”McAffer 说。 “所以我们最终创建了现在所谓的开源门户，它可以作为开源在 GitHub 上使用。” -That’s when the exploration of what Microsoft could do with open source began in earnest, McAffer said. In the early days, if anyone in the company was interested in doing anything with open source, they came to the centralized group for assistance from the open source developers, contributors, and maintainers involved. + 在 opensource.microsoft.com 上很容易看到其中的元素，但还有一个内部方面，Microsoft 员工在其中管理存储库和团队。 -Around the year 2014, things began to change. Microsoft decided to make open source pervasive throughout the company and rolled open source into the main engineering groups. + McAffer 解释说：“我们已经将其开源，其他公司也在内部使用它，因此这是一个双向的事情。” -> "If that’s all we had done, we would have left an untenable vacuum around how we do open source," said McAffer. “Someone has to think about policy and how all the open source efforts would be coordinated, the processes and tools they would use, how would we keep track of projects, etc. So, we created what is now known as the Open Source Programs Office to handle all those issues.” + GitHub 是一个非常丰富的环境，可以进行很多交互。与许多公司一样，微软发现很难跟踪正在发生的一切并了解其存储库发生了什么。 -Some of the technical people from the earlier open source group moved to the newly formed program office, while the others joined engineering groups pertinent to their work. It turned out that Microsoft needed additional talent to make sure all projects and processes were fully manned, and so recruitment efforts, both internally and externally, were soon under way. Today, open source is a thriving part of Microsoft’s global works. + “我们最终参与了 GHTorrent 项目。我们和他们做了很多工作，实际上我们现在正在赞助 GHTorrent 项目，所以我们为他们所有的 Azure 资源付费，你可以在 GHTorrent.org 上看到的一切，”他说. -#### Business and Programmatic Goals + GHTorrent 帮助 Microsoft 了解 GitHub 上发生的事情，也了解其内部项目的情况。即便如此，有些事情 GHTorrent 没有设置，包括使用私有存储库和一些关于需要管理员权限的团队的更详细的数据。 -Microsoft does not have a central open source strategy or a central approval body. Instead, the Open Source Programs Office facilitates those discussions and decisions throughout the company. Teams still need to have their open source engagement reviewed, but it is done more locally. + 该公司最终创建了另一个名为 GHCrawler 的系统，它也开源了。此工具可跟踪 GitHub 上的所有内容，直至提交级别、团队和权限更改。然后将这些数据用于指标和跟踪分析，以发现洞察力，例如有多少拉取请求、他们采取行动的速度以及关闭或合并需要多长时间。 “它为我们提供了一种跟踪我们存在的方式，”McAffer 说。 -> "They know their business, they understand how they want their technical interactions to work, where they want to drive in terms of ecosystems, and all the various nuances of what needs to happen," McAffer said. + **简化开源使用** -> "We defer most of those decisions and directions to the local management, but we give them a structure in which to think about those decisions and directions. We do have central policies about how we manage IP and what we do about security issues. We give them tools and processes that embody those policies to make it super simple for them to execute in a coherent yet specific way." + 在微软，开源的消费是完全不同的事情，也是不同的过程。该公司以多种方式使用开源，并且需要大量跟踪它们并管理法律安全方面。 -#### The Tools to Manage + “我们做了大量的工作来简化开源使用的流程和政策，真正了解成为一个负责任的开源消费者的关键属性，如何正确地做到这一点，并确保我们遵守许可证，”麦卡弗说。 -Microsoft’s policies boil down into processes that then are tooled accordingly to handle the workload. One example is open source releases. As a matter of policy, releases are made on GitHub. + “为此，我们在内部编写了很多工具来发现、跟踪和监控那里发生的事情并报告开源的使用情况，”他继续道。这些工具也往往有些专有，因为它们与 Microsoft 的工程系统深度集成。 -> "We’ve got a bunch of tooling around our presence on GitHub, where we manage something like 10,000+ repos across about 100 organizations with about 12,000 Microsoft people interacting in that space," said McAffer. + “我们一直在努力寻找可以梳理出这些问题的方法，并将更多的内容提供给更广泛的开源社区，但这有点困难，因为它在许多方面对我们的业务政策或工程系统非常具体，这不会和其他人一样，”麦卡弗说。 -> "That gets up to a scale where you really need a system to manage a multitude of aspects. For example, when people want to contribute to one of the projects that we’re running, we need tools to help manage the contributor license agreements or CLA’s. For all of those things, we’ve either built up solutions ourselves or turned to open source solutions." For example, for CLA management, Microsoft uses [CLA Assistant](https://cla-assistant.io/) , an open source program that SAP originated. + 多年来，微软的开源之旅一直很有趣，本着真正的开源精神，我们将继续与大家分享我们在这个过程中学到的东西，从工具到代码。 -> "On the GitHub management side, we went the other direction, as there wasn’t an existing set of tooling to help manage an enterprise presence on GitHub," said McAffer. “So we ended up creating what’s now called the [open source portal](https://github.com/Microsoft/opensource-portal) , which is available on GitHub as open source.” + ### 4.4.4 Salesforce -Elements of that are easily seen on [opensource.microsoft.com](https://opensource.microsoft.com/) , but then there’s an internal side, too, where Microsoft employees manage repos and teams. + Salesforce 很早就了解到，当开源项目拥有多元化的利益相关者社区时，它们会保持健康，这些利益相关者有兴趣使软件取得成功。 -> "We’ve open sourced that and other companies are picking it up and using that internally for themselves, so it’s a bi-directional thing," McAffer explained. + Apache Phoenix 在 Salesforce 开始作为其自己的开源 Phoenix 项目。但是直到 Salesforce 外部的人也得到投资并且该项目不再依赖于一家公司的需求和愿望之后，它才取得成功。在真正的社区努力中，来自其他公司的人加入并说，'这对我们很有用，我们希望做出贡献，'”最近在那里领导开源项目的 Salesforce 软件架构师 Ian Varley 说。 ，这个多元化的社区使它成为一个 Apache 项目并整合了公司自己的工程师永远无法想象的新功能。 -GitHub is a very rich environment, where lots of interactions are possible. Microsoft, like a lot of companies, was finding it difficult to keep track of everything going on and understanding what was happening with its repos. + Salesforce 始终专注于培养不同兴趣以使用和参与其项目的概念。与此同时，它同样专注于将其内部利益相关者——从工程到法律、营销和公关——与其开源工作保持一致。 -> "We ended up engaging with the GHTorrent project. We did quite a bit of work with them, and we actually are now sponsoring the GHTorrent project so we pay for all their Azure resources, everything you can see at [GHTorrent.org](http://ghtorrent.org/)," he said. + **开源项目目标** -GHTorrent helps Microsoft understand what’s going on at GitHub but also internally in terms of its own projects. Even so, there are some things that GHTorrent was not set up to do, including work with private repositories and some of the more detailed data concerning teams where admin permissions are required. + Salesforce 有许多围绕开源的优先事项。该公司的开源战略让每个人都保持一致。专门的开源项目团队将内部文件分发给公司的工程团队，提供战略指导并鼓励开源的创建和使用。这些文件为开源文化奠定了基础，并让团队毫不含糊地知道公司的领导者完全支持该战略。 -The company ended up creating another system called [GHCrawler](https://github.com/microsoft/ghcrawler) , which it also open sourced. This tool tracks everything on GitHub down to the commit level, team, and permissions changes. That data is then used in metrics and tracking analysis to discover insights such as how many pull requests are coming in, how fast they are getting action, and how long they take to close or merge. "It gives us a way of tracking our presence," said McAffer. + 开源越来越多地成为每家公司中几乎每个软件项目的一部分。按理说，开源可以拥有的每一种可能类型的商业模式都会出现并在市场上尝试。 -#### Simplifying Open Source Use + Salesforce 是一家软件即服务供应商，不会发布其作为开源销售的面向最终客户的产品。相反，工程团队专注于开源共享基础架构组件、库和其他公司可能认为通常有用的工具，以及对其客户有益的示例和 SDK。 -Consumption of open source is an entirely different matter, and a different process, at Microsoft. The company uses open source in myriad ways, and the need to track them all and to manage the legal security aspects is enormous. + **衡量开源的成功** -> "We’ve done a massive amount of work to simplify the processes and the policies around open source use, to really understand the key attributes of being a responsible consumer of open source, how to do it right, and to make sure we adhere to the licenses," McAffer said. + 该公司开源项目的目标之一是在开发人员中建立声誉。可能不使用Salesforce产品的工程师有时会看着该公司的开源项目说，“嘿，这家公司确实参与了一些很棒的东西，”Varley说。 -> "To that end, we’ve written a lot of tools internally to discover, track, and monitor what’s going on there and report on the use of open source," he continued. Those tools also tend to be somewhat proprietary as they are deeply integrated with Microsoft’s engineering systems. + “开源为(外部开发者)提供了一个窗口，让他们看到公司内部正在进行的伟大工程，否则他们无法看到。”——Ian Varley, Salesforce的软件架构师。 -> "We’ve been trying to see ways we can tease that out and make more of that available to the open source community more broadly, but it’s been a bit hard because it is very specific in many ways to our business policy or our engineering system, which isn’t going to be the same as anybody else’s," McAffer said. + 开源项目还关注于扩大公司自己的开源项目背后的社区。社区不只是使用他们的软件，他们也为它做出贡献。因此，他们专注于为他们的项目创建“斜坡”，比如一个清晰的补丁审批流程、改进的文档、健康的论坛，以及欢迎和响应的维护人员。 -The Microsoft open source journey has been an interesting one over the years and in the true open source spirit, we will continue to share what we learned with everyone in that process, from tools to code. + “当我们给人们提供参与我们项目的方法时，我们就成功了，这些方法不需要他们有博士学位，或者在类似领域工作了25年。你需要让他们迅速参与进来，”瓦利说。 -### Salesforce + Salesforce还将自己的成功与开源行业的成功进行了对比。开源在各个方面取得的进步越多，每个人就越幸福，因为开源越多就意味着整个行业取得的进步越多。如果Salesforce能够提高什么是商品软件，什么是每个人都可以依赖的共享组件的基线，那么整个行业都会受益。 -Salesforce learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed. + **Apache Phoenix** -[Apache Phoenix](https://phoenix.apache.org/) started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’" says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up. + Apache Phoenix是一个开源大数据分析平台，现在是 Apache 软件基金会的一部分。但是当 Phoenix 开始时，它只是几个 Salesforce 工程师为一些特定的内部用例构建的项目。但是，不久之后，这个小团队意识到任何人都可以从该项目中受益，如果全世界都在为它工作，它的速度会提高。因此，他们努力将其开源并将其转变为社区项目。 -Salesforce stays focused on this concept of cultivating diverse interests to use and participate in its projects. At the same time, it’s equally focused on aligning its internal stakeholders – from engineering to legal, marketing and PR – with its open source efforts. + 在创建开源 Phoenix 项目的第一年，Salesforce 工程师开始从发现 Phoenix 并希望加入该项目的两三个大公司那里获得重要的功能贡献。通过将项目开放给外部使用和贡献，Phoenix 项目的进展远远超出了原始工程师自己能够完成的工作。 -#### Open Source Program Goals + **5个关键经验** -Salesforce has many priorities around open source. The company’s open source strategy keeps everyone aligned. The dedicated open source program team circulates internal documents to the company’s engineering team that provide strategic guidance and encourage the creation and use of open source. The documents provide the foundation for an open source culture and let the team know in no uncertain terms that the company’s leaders are fully behind the strategy. + 回顾他在 Salesforce 管理开源的 4 年经验，Varley 为可能刚刚开始使用自己的开源程序的公司提供了五个关键经验： -Open source is increasingly a part of just about every software project in every company that’s out there. It stands to reason that every possible type of business model you can have with open source is going to come into being and try its hand in the market. + - 制定公司范围内的政策，强烈鼓励在内部使用和创建开源。 + - 认识到社区可以推进项目远远超出内部可以实现的目标。 + - 从许多不同类型的利益相关者那里寻求关于你的开源项目的意见。工程师不应该是唯一的利益相关者——例如，您的法律团队和执行管理层也应该直接参与。 + - 通过出色的设置文档和健康的论坛，专注于您的开源项目的良好“坡道”。 + - 认识到开源的成功可以推动整个行业的成功和更好的产品。 -Salesforce is a Software-as-a-service vendor, and doesn’t release the end customer-facing products that it sells as open source. Instead, the engineering team focuses on open sourcing shared infrastructure components, libraries, and tools that other companies might find generally useful, as well as samples, and SDKs that are of benefit to their customers. - -#### Measuring Open Source Success - -One goal of the company’s open source program is building its reputation among developers. Engineers who may not use Salesforce products will sometimes look at the company’s open source projects and say, "Hey, this company is really involved with some great stuff," Varley said. - -> "Open source is a window for (external developers) to see the great engineering that’s going on inside of the company that they otherwise wouldn’t be able to." – Ian Varley, Software Architect at Salesforce. - -The open source program also focuses on expanding the communities that align behind the company’s own open source projects. The communities don’t just use their software, they also contribute to it. So they focus on creating "on ramps" to their projects such as a clear approval process for patches, improved documentation, healthy forums, and welcoming and responsive maintainers. - -> "We’ve succeeded when we have given people ways to get involved with our projects that don’t require them to have a PhD or to have been working in a similar area for 25 years. You need ways for them to get involved quickly," Varley says. - -Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source, in all of its many dimensions, the better off everyone is because more open source means more progress in the industry as a whole. If Salesforce can raise the baseline of what is commodity software and what constitutes shared components that everybody can depend on, the whole industry benefits. - -#### Apache Phoenix - -Apache Phoenix is an open source big data analytics platform that’s now part of the Apache Software Foundation. But when Phoenix started, it was just a project a couple of Salesforce engineers built for some specific internal use cases. But, before long, the small team realized that anybody could benefit from the project and its velocity would improve if the whole world was working on it. So they made the pitch to open source it and turn it into a community project. - -Within the first year of creating the open source Phoenix project, the Salesforce engineers started getting significant contributions in functionality from two or three big companies that had found Phoenix and wanted to join the project. By opening the project up to outside use and contribution, the Phoenix project progressed far beyond what the original engineers would have been able to do on their own. - -#### 5 Key Lessons - -Looking back at his 4 years of experience managing open source at Salesforce, Varley has five key lessons for companies that may just be getting started with their own open source programs: - -* Create a company-wide policy that strongly encourages the use and creation of open source internally. -* Recognize that a community can advance a project far beyond what can be achieved internally. -* Seek input on your open source program from many different types of stakeholders. Engineers should not be the only stakeholders—your legal team and executive management should also be directly involved, for example. -* Focus on good "on ramps" to your open source projects with great set up documentation and healthy forums. -* Recognize that open source success can drive industry-wide success and better products everywhere. - -### Additional Resources - -This module has covered a variety of information related to helping your organization create its own Open Source Program Office, but there is more detail and nuance than can be fully covered in this course. Therefore, we are including some additional resources that you can use to see case studies and/or get more information about this topic: - -* TODO Group: [https://todogroup.org/](https://todogroup.org/) - -* What Does An Open Source Program Office Do? (Red Hat Blog): [https://www.redhat.com/en/blog/what-does-open-source-program-office-do](https://www.redhat.com/en/blog/what-does-open-source-program-office-do) - -* How Google Created a New Kind of Open Source Program Office (Opensource.com): [https://opensource.com/business/16/9/google-open-source-program-office](https://opensource.com/business/16/9/google-open-source-program-office) - -* I’ve Got an Open Source Program Office, Now What? (Bitergia Blog): [https://blog.bitergia.com/2019/03/05/ive-got-an-open-source-program-office-now-what/](https://blog.bitergia.com/2019/03/05/ive-got-an-open-source-program-office-now-what/) +* https://blog.bitergia.com/2019/03/05/ive-got-an-open-source-program-office-now-what/) diff --git a/sources/OSPO-101/module4/README.md b/sources/OSPO-101/module4/README.md index 721006d..5b3514a 100644 --- a/sources/OSPO-101/module4/README.md +++ b/sources/OSPO-101/module4/README.md @@ -1,563 +1,543 @@ --- -status: collected +status: translated title: "OSPO 101 Training Modules - Module 4" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module4/README.md --- -# Effective Open Source Development & Participation +# 一、介绍 -## Lesson: Introduction +## 1.1 简介 -### Section Overview +在本节中，我们将探索开源开发和社区参与中使用的核心概念和实践，并将它们与传统的闭源开发进行比较。 -### In this section, we will explore the core concepts and practices used in open source development and community participation and compare them with traditional closed-source development. +## 1.2 学习目标 +在本节结束时，您应该能够： -### Learning Objectives +- 解释核心开源实践及其在有效的开源开发和社区参与中发挥的作用 +- 与闭源软件开发相比，阐明这些概念的差异（和相似之处） -By the end of this section, you should be able to: +# 2. 需求与设计 -* Explain core open source practices and the role they play in effective open source development and community engagement -* Articulate the differences (and similarities) of these concepts when compared to closed-source software development +## 2.1 开源软件开发的要求 -## Lesson: Requirements & Design +需求是任何形式的软件开发的关键考虑因素，开源也不例外——然而，需求收集的形式和功能与许多传统软件开发环境中使用的“瀑布”需求过程有很大不同。 -### Requirements in Open Source Software Development +考虑一下典型的开源开发模型的一般概述： -Requirements are a key consideration for any form of software development, and open source is no different - however, the form and function of requirements gathering is significantly different than the ‘Waterfall’ requirements processes used in many traditional software development environments. +![Image description](open-source-development-model.png) -Consider this general overview of a typical open source development model: +正如您从这张图中看到的，“需求”通常以来自用户或开发人员的“功能请求”的形式出现，并且由于开发的迭代/敏捷性更强（稍后会详细介绍），没有很长时间 , 开源软件开发的长期需求阶段。 -![open-source-development-model](open-source-development-model.png) +这具有独特的优势，因为它利用了对不断变化的需求或项目运营所在的技术和业务环境做出快速响应的能力。 但是，它确实需要严格的开发人员纪律，以及帮助管理项目长期战略目标的核心开源维护人员。 -As you can see from this graphic, ‘requirements’ generally come in the form of ‘feature requests’ from users or developers, and due to the more iterative/Agile nature of development (more on that shortly), there isn’t a long, protracted requirements phase for open source software development. +应该指出的是，这些原则中有许多是敏捷软件开发方法论的一部分，并且确实有许多相似之处。 我们将在后面的部分讨论一些细微的差异。 -This has unique advantages in that it harnesses the ability to respond rapidly to changing requirements or the technology & business landscape in which the project is operating. However, it does require significant developer discipline, as well as core open source maintainers who are also helping to manage the long-term strategic goals of the project. +## 2.2 传统封闭软件开发中的需求 -It should be noted that many of these principles are part of the [Agile Software Development Methodology](https://en.wikipedia.org/wiki/Agile_software_development), and indeed there are many similarities. We’ll discuss some slight differences in later sections. +虽然越来越多的软件开发采用敏捷和/或 DevOps 方法进行软件设计，但仍有大量传统的闭源或专有软件开发模型采用更“瀑布”的方法，如下所示： +![Image description](waterfall-model.png) -### Requirements in Traditional Closed Software Development +虽然这种方法在文档的完整性方面确实有一些优势（例如），但它通常被认为过于重量级，并且比开源软件项目采用的更具迭代性或敏捷性的方法要慢得多。 此外，大多数开源软件项目中存在的典型地理分散开发团队通常更难以实施。 -While more and more software development has adopted Agile and/or [DevOps](https://en.wikipedia.org/wiki/DevOps) approaches to software design, there are still significant pockets of traditional closed-source or proprietary software development models that take a more ‘Waterfall’ approach, as illustrated here: +## 2.3 开源项目特点 -![waterfall-model](waterfall-model.png) +我们将在以后的模块中更详细地介绍与上游开源项目的合作，但是在您构建有效的开发实践以与这些社区互动之前，了解大多数开源项目的几个共同特征很重要。 -While this approach does have some advantages in thoroughness of documentation (for example), it’s generally considered too heavyweight and significantly slower than the more iterative or Agile approach that open source software projects take. Additionally, it’s generally more difficult to implement with the typical geographically-dispersed development teams that exist in most open source software projects. +虽然这不是一个详尽的清单，但这里列出了几乎所有开源项目的一些核心特征： -### Open Source Project Characteristics +- 地域分布的开发团队 +- 透明的沟通和开发实践 +- 分布式和透明/公开的决策 +- 精英文化（那些做工作的人有助于推动项目方向） +- 适应组织变革 +- 自组织 +- 可扩展的项目开发/管理模型 +- 所有代码贡献的同行评审 -We will be covering working with upstream open source projects in more detail in a future module, but there are several common characteristics of most open source projects that are important to understand before you can build effective development practices to engage with these communities. +## 2.4 可扩展的开发模型 -While this is not an exhaustive list, here are some core characteristics of almost all open source projects: +成功的开源开发工作的一个标志是能够根据可用的参与量有效地扩展项目。 以下是使之成为现实的结构示例： -* Geographically-distributed development teams -* Transparent communication and development practices -* Distributed and transparent/open decision-making -* Meritocratic cultures (those doing the work help drive project direction) -* Resilience to organizational change -* Self-organization -* Scalable project development/management models -* Peer review of all code contributions +![Image description](single-body-of-code.png) -### Scalable Development Models +小型项目通常只有一个维护者和一小部分代码。 发布通常没有严格的时间安排，而是在“准备就绪”时发布。 -A hallmark of successful open source development efforts is the ability to scale projects effectively depending upon the amount of participation available. Below are examples of the structures that make that a reality: +![Image description](code-diveded-into-subsystems.png) -![single-body-of-code](single-body-of-code.png) +随着项目开始变得稍微大一点，它们仍然具有不规则的发布周期，但可能会开始将代码库划分为子系统。 在这个阶段，他们通常仍然只有一个维护者。 +![Image description](release-criteria-become-more-stringent.png) -Small projects usually have a single maintainer and a small body of code. Releases are usually not strictly scheduled and are put out ‘when they are ready’. +随着项目趋向于中等规模，它们通常仍然只有一个维护者，但它们的发布标准将开始变得更加严格，定期发布。 -![code-diveded-into-subsystems](code-diveded-into-subsystems.png) +![Image description](delegated-maintainership.png) +一旦项目通过了中等规模的标记，他们就会开始考虑委托维护，在这种情况下，主要维护者不能再照顾项目中的每个子系统。 可能对特定子系统具有专业性或热情的受信任的开发人员/贡献者被指定负责该特定的代码体。 -As projects start to get slightly bigger, they still have irregular release cycles, but may start to divide the codebase into subsystems. At this stage they still usually only have a single maintainer. +![Image description](release-overseen-by-decicated-maintainers.png) -![release-criteria-become-more-stringent](release-criteria-become-more-stringent.png) +一旦项目升级到“大型”类别，就会发生一些变化——子系统的进一步划分（有时甚至分为更离散的部分）以及更详细的委派维护和发布级别，这些不仅是定期的，而且由一个 专门的维护者集，例如 Linux 内核的 LTE（长期演进）内核分支。 +这些结构和开发模型的一个关键要素是，它们通过将不同项目子系统的责任委托给“维护者”来发挥作用，“维护者”对子系统中的代码负有最终责任。 这允许一定程度的专业化和监督，使整个项目维护者能够专注于项目的更大战略和架构图。 -As projects trend toward medium-sized, they still usually have a single maintainer, but their release criteria will start to become more stringent, with regularly-scheduled releases. +## 2.5 可扩展项目示例 - Linux -![delegated-maintainership](delegated-maintainership.png) +作为成功的项目如何在实践中实施这种可扩展开发模型的示例，请考虑世界上最成功的开源项目之一 Linux Kernel： +![Image description](linux-example.png) -Once projects pass the medium-sized mark, they start to look toward delegated maintainership, where the primary maintainer can no longer look after every single subsystem in the project. Trusted developers/contributors who may have speciality or passion for a particular subsystem are appointed to look after that specific body of code. +尽管 Linus Torvalds 仍然保持对该项目的整体影响力，但他严重依赖一组分布式维护者来维护作为内核一部分的不同子系统。 并非每个开源项目都发展到这种规模或需要这种级别的控制，但考虑如何在庞大且多样化的贡献者基础上实施有效控制是有益的。 -![release-overseen-by-decicated-maintainers](release-overseen-by-decicated-maintainers.png) +## 2.6 开源中的设计注意事项 -Once projects graduate to the ‘large’ category, there are several changes - a further division of subsystems (sometimes into even more discrete parts) as well as a more detailed level of delegated maintainership and releases that are not only regular, but overseen by a dedicated set of maintainers, such as the Linux kernel’s LTE (Long-term Evolution) kernel branch. +现在我们已经了解了一些开源项目的特征和组织模型，让我们考虑一下开源项目中成功设计实践的一些核心原则。 -A key element to these structures and development models is that they function by delegating responsibility for different project subsystems to ‘maintainers’ who have ultimate responsibility for the code in their subsystem. This allows a level of specialization and oversight that frees up the overall project maintainer(s) to focus on the larger strategic and architectural picture of the project. +重要的是要考虑设计如何在开源项目中表现出来，以及它与更传统的软件开发有何不同。 主要考虑分为三个主要方面： -### Scalable Project Example - Linux +- 开放式设计 +- 招聘其他人 +- 验收设计 -As an example of how successful projects implement this scalable development model in practice, consider one of the world’s most successful open source projects, the Linux Kernel: +让我们在接下来的页面中更详细地了解这些。 -![linux-example](linux-example.png) +### 2.6.1 开放式设计 -While Linus Torvalds still maintains overall influence over the project, he relies heavily on a distributed set of maintainers for the different subsystems that are part of the kernel. Not every open source project grows to this size or needs this level of control, but it’s informative to consider how effective control can be implemented over a large and diverse contributor base. +开放和透明是开源开发的标志，设计也不例外。以下是“开放式设计”的一些最佳实践： -### Design Considerations in Open Source +- 尽早并经常在项目首选的交流平台上进行交流 +- 提供代码示例和可能的参考实现 +- 预期反馈 +- 承认良好的反馈并重新工作你的贡献 +- 及时回复问题，尤其是来自潜在贡献者的问题 +- 如果其他人愿意做这项工作，则表示愿意调整您的设计 +- 计划模块化，即使最初的设计不是模块化的 +- 灵活性也是这里的一个关键要素 - 与传统的闭源项目相比，了解您的代码正在被更多的人评估和查看对于帮助您做出最佳设计决策并使您的代码贡献被项目接受非常重要。 -Now that we’ve looked at some open source project characteristics and organizational models, let’s consider some core tenets of successful design practices within open source projects. +采用模块化方法（或至少规划如何使代码模块化）也与传统开发模型不同，在传统开发模型中，单体设计往往更为普遍。从一开始就考虑模块化不仅有助于整个开源项目，而且它本身就是一个很好的工程实践。 -It’s important to consider how design manifests itself within open source projects and how that differs slightly from more traditional software development. The main considerations fall into three main areas: +### 2.6.2 招聘其他人 +协作是开源项目中的游戏名称，其方式比您在典型的公司或闭源开发工作中通常习惯的方式要深得多。 -* **Design in the Open** -* **Recruit Others** -* **Design for Acceptance** +当您招募其他人来协助您进行开源时，需要考虑以下一些事项： -Let’s take a look at these in a bit more detail in the following pages. +- 自己挠痒痒，没有人会为你挠痒痒……除非他们有同样的痒痒 +- 为了减轻你的开发负担，编写能够吸引他人的代码 + - 确保您的贡献范围足够广泛以吸引其他开发人员 + - 如果有人表示对您的代码感兴趣，请积极响应 +- 如果它是竞争对手，请不要感到惊讶 + - 通常，从开源项目的功能中获益最多的公司都在同一业务线中 + - 竞争对手之间有着丰富的开源合作历史 -### Design in the Open +与范围更窄的开发实践相比，在设计代码时考虑到其他人确实需要更多的时间和精力，但是当您亲眼目睹有效的开源项目贡献者基础的倍增效应时，这最终是值得的。 -Openness and transparency are hallmarks of open source development, and design is no different. Here are some best practices for ‘designing in the open’: +### 2.6.3 验收设计 -* Communicate early and often on the project’s preferred communication platform -* Provide code examples and possibly reference implementations -* Anticipate feedback - * Acknowledge good feedback and re-work your contribution -* Respond promptly to questions, particularly from potential contributors - * Signal willingness to adapt your design if someone else will do the work -* Plan for modularity, even if the first designs are not modular +基于到目前为止所说的一切，此时应该很清楚，您参与开源的目标应该是考虑如何有效地接受您的设计和想法。 -Flexibility is also a key element here - understanding that your code is being evaluated and viewed by more eyes than in a traditional closed-source project is important to help you make the best design decisions and get your code contribution accepted into the project. +需要考虑的一些事项是： -Taking a modular approach (or at least planning for how you can make your code modular) is also something that can be different from a traditional development model, where monolithic designs tend to be more prevalent. Thinking about modularity from the start not only helps the overall open source project, it’s a good engineering practice in and of itself. +- 将您的贡献设计为以尽可能小的部分编写和集成 + - 维护人员更容易集成较小的补丁 + - 开源项目偏爱模块化方法，因为它促进了可扩展性 +- 适当地确定设计范围，并在必要时细分您的计划 + - 较大的更改更有可能被采用为具有具体里程碑的一系列较小的更改 + - 传达您的总体计划以提供背景信息，但不要期望立即获得普遍支持 +- 尽可能不干扰其他项目子系统 + - 如果您认为需要更改核心系统组件，请提前沟通并在开始之前征求维护人员的意见 +如果您将自己置于必须集成或稍后维护您的代码的其他开发人员或维护人员的位置，这将有助于为您提供正确的设计接受度。 -### Recruit Others +# 3. 决策与发展节奏 -Collaboration is the name of the game in open source projects, and in a much deeper way than you may normally be used to in a typical corporate or closed-source development effort. +## 3.1 决策过程和沟通期望 -Here are some things to think about as you recruit others to assist you in open source: +除了考虑以新的方式进行设计之外，了解在开源项目中如何制定（和传达）决策也很重要。通常，下面列出的原则与传统的软件开发方法略有不同： -* Scratch your own itch, nobody else will scratch it for you… unless they have the same itch -* To decrease your development burden, write code that will attract others - * Make sure your contribution is scoped broadly enough to attract other developers - * Be responsive and proactive if someone indicates interest in your code -* Don’t be surprised if it’s a competitor - * Often the companies with the most to gain from a feature in an open source project are in the same line of business - * There is a rich history of open source collaboration between competitors +- 通过任命受信任的代表（通常称为“子系统维护者”）来分散决策 +- 信任是建立在过去良好参与和对较小问题的明智决策的记录之上的 +- 去中心化性质需要额外关注透明度 + - 讨论总是公开进行 + - 示例：邮件列表、IRC、Slack 等。 +- 通常讨论本身就是结果的文件记录（因此档案很重要） -Designing your code with others in mind does take more time and effort than more narrowly-scoped development practices, but it is worth it in the end when you witness the multiplicative effect of an effective open source project’s contributor base. +简而言之，电子形式的交流不仅对开源项目至关重要，而且通常比在传统软件项目中的讨论频率和深度更高，在传统软件项目中，您可能只与直接的开发同行进行交流。 -### Design for Acceptance +了解并准备好以这种稍微不同的方式进行交流很重要，我们将在本培训的后面部分详细介绍如何处理此问题。 -Based on everything said so far, it should be clear at this point that your goal in participation within open source should be to think of how you get effective acceptance of your designs and ideas. +## 3.2 开发过程和节奏 -Some things to consider to help with this are: +让我们将本培训中前面展示的图形带回来，以更好地了解开源开发过程如何与节奏相关： -* Design your contribution to be written and integrated in the smallest parts possible - * Smaller patches are easier for maintainers to integrate - * Open source projects favor a modular approach, because it promotes extensibility -* Properly scope the design, and subdivide your plans if necessary - * Larger changes are more likely to be adopted as a series of smaller changes with concrete milestones - * Communicate your overall plan to provide context, but don’t expect universal buy-in right away -* Be as non-intrusive as possible to other project subsystems - * If you believe you need to change a core system component, communicate far in advance and solicit input from their maintainers before getting started +![Image description](open-source-development-model.png) -If you put yourself in the shoes of another developer or maintainer who has to integrate or later maintain your code, it will help give you the proper perspective for designing for acceptance. +开源项目遵循“尽早发布，经常发布”的口号。虽然根据上图这似乎很明显，但它具有影响开发过程和节奏的元素，特别是： -## Lesson: Decisions & Development Cadence +- 第一次不要期望代码完美 + - 当代码运行良好以实现您的目标时提交代码 + - 代码稳定是社区进程的一部分 + - 允许开发者社区帮助指导和塑造代码 +- 以尽可能小的合理块实现功能 + - 小改动更容易测试和集成 +- 准备好重新编写您的代码（可能多次）以使其被接受 -### Decision Process & Communication Expectations +开源项目中代码提交/返工的节奏对于习惯了更传统软件开发环境的开发人员来说通常是最大的不同，开源项目中使用的更高的速度可能需要一点时间来适应。然而，一旦你熟悉了这种工作方式，你可能会发现以这种方式工作变得更加自然，几乎是第二天性。 -In addition to thinking about designing in a new way, it’s important to understand how decisions are made (and communicated) in an open source project. Often, the tenets listed below are a bit of a departure from traditional software development methodologies: +# 4. 与大型分布式开发团队合作 -* Decisions are decentralized by appointing trusted delegates, usually called “subsystem maintainers” -* Trust is built by past record of good participation and wise decisions on smaller issues -* Decentralized nature requires an extra focus on transparency - * Discussions always happen in the open - * Examples: Mailing lists, IRC, Slack, etc. -* Often the discussion itself is the documented record of the outcome (archives are therefore critical) +## 4.1 社区 -In short, communication in electronic forms is not only critical to open source projects, there is usually more discussion frequency and depth than in a traditional software project where you may only be communicating with your immediate development peers. +从本培训的前面部分可以看出，与开源项目及其社区合作的动态与您习惯于严格的公司或内部开发工作的动态略有不同。 -Understanding and preparing yourself to communicate in this somewhat different way is important, and we’ll cover more about how to approach this in later sections of this training. +社区的概念并不难理解——我们大多数人都生活在社区中，并且在日常生活中经历过不同层次的社区。然而，当应用于开源项目时，有一些事情需要考虑： -### Development Process & Cadence +- 没有两个社区是完全相同的 +- 社区不适用于个别公司 -Let’s bring the graphic presented earlier in this training back to get a better idea of how an open source development process works with regard to cadence: +有一些众所周知的开源项目社区，例如 Linux 内核或 Kubernetes，它们有一些相似之处，但“个性”不同，这通常是它们的启动方式、实施的治理模型以及经验的结果他们的创始成员。 -![open-source-development-model](open-source-development-model.png) +虽然现在很多组织都在投资开源（例如，Kubernetes 是由 Google 创立的），但开源项目社区并不为个别公司工作，因此为您的组织完成工作就变成了持续的贡献和做得很好（稍后会详细介绍）。 -Open source projects live by the mantra ‘**Release Early, Release Often**.’ While this may seem obvious based on the graphic above, it has elements that affect the development process and cadence, specifically: +了解开源项目不是您组织的“免费开发人员”非常重要，因为做出这种假设可能会在以后导致有问题的挑战。在接下来的几页中，我们将为您提供一些与开源社区互动的最佳实践，并向您展示一些基本的通信工具礼仪将如何帮助您与这些大型分布式开发团队有效合作。 -* Don’t expect code perfection the first time - * Submit code when it works well enough to address your goal - * Code stabilization is part of the community process - * Allow the developer community to help guide and shape the code -* Implement functionality in the smallest reasonable chunks possible - * Small changes are easier to test & integrate -* Be prepared to rework your code (potentially multiple times) to get it accepted +## 4.2 准备参与 -The cadence of code submissions/rework in open source projects is usually the biggest difference for developers used to a more traditional software development environment, and the higher pace used in open source projects will likely take a bit of getting used to. However, once you are familiar with this way of working, you’ll probably find that it becomes more natural and almost second-nature to work in this fashion. +在您开始直接与社区合作之前，花点时间研究并准备最佳方法来让您走上正轨，这通常是有益的。这项研究的一部分是着眼于您（或您的组织）准备做什么来支持社区。 -## Lesson: Working with Large Distributed Development Teams + **确定您必须提供什么** -### Communities +开源项目不仅仅是代码 - 您可以在许多领域做出贡献： -From earlier sections of this training, it’s hopefully obvious that the dynamics of working with open source projects and their communities is a bit different than what you may be used to with strictly corporate or internal development efforts. +- 软件开发 +- 测试/质量保证 +- 文档 +- 用户体验/图形用户界面设计 +- 布道/通讯 -The concept of community isn’t difficult to understand - most of us live in communities and are experienced with different levels of community in our daily lives. When applied to open source projects however, there are some things to consider: +如果您在多个这些领域拥有专业知识，您当然可以在多个角色中做出贡献。 -1. **No two communities are exactly the same** -2. **Communities don’t work for individual companies** + **确定你的时间承诺** -There are well known open source project communities, such as the Linux kernel, or Kubernetes that have some similarities, but different ‘personalities’, which are usually the result of how they were started, the governance models put into place, and just the experiences of their founding members. +如果您和/或您的组织对您可以带来什么样的时间投入持现实态度，这会有所帮助。尝试致力于您可以实际交付的内容，因为大多数社区尊重已完成的工作，而不是空洞的帮助。 -While it’s true that a lot of organizations now invest in open source (Kubernetes, for example, was started by Google), open source project communities don’t work for individual companies, so getting things done for your organization becomes about making sustained contributions and doing good work (more on that in a bit). +另请记住，您的承诺不仅体现在您身上，还体现在您所代表的组织上。 -Understanding that open source projects aren’t your organization’s ‘free developers’ is very important, as making that assumption can lead to problematic challenges later on. In the next few pages we’ll give you some best practices for engaging with the open source community and show you how some basic communications tool etiquette will go a long way toward helping you work effectively with these large distributed development teams. +## 4.3 了解社区 -### Preparing to Engage +在您制定与社区互动的计划时，重要的是要了解他们是谁以及他们如何工作的一些重要事项。 -Before you jump into directly working with a community, it’s often beneficial to take a bit of time to research and prepare the best approach to get you off on the right foot. Part of this research is looking at what you (or your organization) is prepared to do in support of the community. +### 4.3.1 了解社区如何沟通 -**Determine What You Have to Offer** +显然，了解社区动态的很大一部分是了解他们交流的地点和方式。一些社区仍然更喜欢电子邮件 - 其他社区已迁移到异步论坛，如 IRC（互联网中继聊天）、Slack、Github 问题、Discord 或其他论坛工具。 -Open source projects are about more than simply code - there are many areas you can contribute in: +花一些时间不仅要弄清楚正在使用什么平台，还要潜伏一下，看看会问什么样的问题，如何回答，以及引用了哪些其他信息来源（错误跟踪器、维基等）在社区的回答中。 -* Software Development -* Testing/Quality Assurance -* Documentation -* User Experience/GUI Design -* Evangelism/Communications +通过进行这项研究，并在您在社区中提问之前努力尝试找到答案，您向现有社区成员表明您是认真对待成为一名优秀社区成员的，这将大有帮助。 -If you have expertise in multiple of these areas, you can certainly contribute in multiple roles. +### 4.3.2 了解社区的治理方式 -**Determine Your Time Commitment** +潜伏在交流论坛上并做功课还可以帮助您了解项目的适当治理模型。一些项目是具有清晰命令/报告链的层次结构。一些项目具有更扁平的组织模型。 -It helps if both you and/or your organization is realistic about what kind of time commitment you can bring to the table. Try to commit to what you can realistically deliver, as most communities respect completed work more than hollow offers of help. +了解治理的动态不仅可以帮助您更好地准备做出贡献，还可以帮助您了解社区中的哪些群体最适合回答您可能遇到的任何问题。 -Also remember that your commitment reflects not only on you, but also on the organization you represent. +### 4.3.3 认识人 -### Getting to Know the Community +尽管开源项目默认使用地理分布的团队，但尝试亲自了解社区成员很重要，因为您经常需要帮助（或向他人提供帮助）以获取贡献或想法接受。如果可能，尝试参加许多项目组织的面对面或虚拟聚会，以帮助新项目成员了解已建立的项目老手。 -As you are formulating your plan to engage with the community, it’s important to get to know some critical things about who they are and how they work. +## 4.4 让我们参与吧！ -#### Understand How the Community Communicates +好的，您已经完成了研究，现在您已准备好与开源社区互动！您在参与时应该考虑四个主要方面。 -Obviously, a huge part of understanding the dynamics of a community are understanding where and how they communicate. Some communities still prefer email - others have migrated to asynchronous forums like IRC (Internet Relay Chat), Slack, Github issues, Discord, or other forum tools. +### 4.4.1 沟通你正在做的事情 -Take some time to figure out not just what platform is being used, but lurk around a bit to see what kinds of questions get asked, how they get answered, and what other sources of information (bug trackers, wikis, etc.) get referenced in answers from the community. +不要在“私下”为社区做一些事情，直到它完美为止。记住早先的建议“尽早发布，经常发布”。通常不仅检查沟通渠道以查看您的计划是否已经完成通常是个好主意，而且还可以表明您打算构建新功能的意图或者修复一个错误，以便社区（和维护者）可以帮助您规划让您的贡献被接受的最佳方式。社区希望看到您成功，因此在您准备贡献时让他们帮助您是一个好主意。 -By doing this research, and making an effort to try to find answers before you ask in the community, you are showing existing community members that you are serious about being a good community member, and that goes a long way. +#### 4.4.2 承认您使用的人员和资源 -#### Understand How the Community is Governed +很少有对开源的贡献没有您正在构建的其他代码。请记住感谢您在贡献中使用的任何其他工作/库/开发，并帮助社区找到这些资源，因为它们通常对整个项目有帮助。 -Lurking on communications forums and doing your homework also helps you understand the governance models in place for a project. Some projects are hierarchies with clear chains of command/report. Some projects have a flatter organizational model. +### 4.4.3 回馈社会 -Understanding the dynamics of governance not only helps you be better prepared to contribute, it also helps you know which groups in the community are best suited to answer any questions you may have. +除了代码的明显贡献之外，还可以考虑其他可以回馈社区的方式，例如安排来自组织的硬件礼物（如果可能），或为团队安排聚会，或者只是花时间为新成员回答问题在你之后。 -#### Get to Know the People +代码绝对重要，但真正成功的开源项目也依赖于“非代码”的贡献。 -Though open source projects utilize geographically-distributed teams as a default, it’s important to try to get to know community members personally, as you’ll often be in a position to require help (or give help to others) in getting a contribution or idea accepted. If possible, try to participate in in-person or virtual meetups that many projects organize to help new projects members get to know established project veterans. +### 4.4.4 计划退出策略 -### Let’s Engage! +社区是周期性的——最终，您和/或您的组织可能需要退出社区。尝试让社区保持比进入时更好的状态。您可以做的一些简单的事情是： -Ok, you’ve done your research and now you’re ready to engage with an open source community! There are four main areas you should be thinking about in your engagement. +- 确定接班人或某人来接管您的代码 +- 将该继任者介绍给社区的其他成员 +- 尽快通知社区，以便他们有时间计划因您退出而可能需要进行的任何更改。 -#### Communicate What You’re Working On +请记住，即使在退出社区时，您的行为也会影响您和/或您的组织。 -Don’t work on something for the community ‘in private’ until you have it just perfect. Remember the earlier advice of ‘Release Early, Release Often.’ It’s usually a good idea to not only check the communications channels to see if what you are planning has already been done, but it’s also good to signal your intent to build a new feature or fix a bug, so that the community (and maintainers) can help you plan for the best way to get your contribution accepted. The community wants to see you succeed, so letting them help you as you prepare your contribution is a good idea. +## 4.5 沟通礼仪 -#### Acknowledge People and Resources You Use +大多数项目中使用的两种主要通信工具类型是某种消息传递系统（电子邮件、Slack、IRC 等）和某种问题或错误跟踪软件（JIRA、Github 问题等）。以下是有效使用每种平台的一些一般提示： -Very few contributions to open source are devoid of other code that you’re building upon. Remember to acknowledge any other work/libraries/developments you used in your contribution, and help the community find these resources too, as they can often be helpful to the entire project. +### 4.5.1 消息传递 -#### Give Back to the Community +- 大多数消息/通讯都是英文的 +- 反馈很可能是短时间/集中爆发的 +- 尽量不要对代码进行个人批评，而是接受好的建议并重新编写代码 +- 如果你正在审查代码，批评代码/想法，但不要批评这个人 +- 注意时区，不一定期望立即响应 +- 如果提出问题，请尝试“展示您的工作”，以便社区可以为您指明正确的方向 -Besides the obvious contribution of code, consider other ways you can give back to the community as well, such as arranging hardware gifts from your organization (if possible), or arranging meetups for the teams, or simply spending time answering questions for the new members that come after you. +### 4.5.2 错误/问题跟踪 -Code is definitely important, but truly successful open source projects thrive on the ‘non-code’ contributions as well. +- 保持错误报告简洁而全面 +- 检查错误/问题系统以查看您报告的内容是否已经存在 +- 提供足够的相关信息，包括触发错误的任何测试代码 +- 了解没有社区义务来修复错误 - 为您可能需要自己修复它的事实做好准备 +- 如果您修复了错误或找到了解决方法，请对信息进行任何相关更新 -#### Plan an Exit Strategy +## 4.6 最重要的四件事要记住 -Communities are cyclical - eventually, you and/or your organization may need to exit the community. Try to leave the community in better shape than you entered it. Some simple things you can do to make this happen are: +当您第一次开始与开源社区合作时，有很多事情需要考虑。 但是，如果您牢记以下四点，它们应该涵盖大多数情况： -* Identify a successor or someone to take over your code -* Introduce that successor to the rest of the community -* Inform the community as soon as possible so that they have time to plan for any changes they may need to make as a result of your exit. +### 4.6.1 了解社区治理 -Remember that even in exiting a community, your behavior reflects on you and/or your organization. +每个社区都不同，但您的所有“补丁”都需要融入整体。 -### Communication Etiquette +### 4.6.2 了解社区动机 -The two main types of communication tools in use within most projects are some sort of messaging system (email, Slack, IRC, etc.) and some sort of issue or bug tracking software (JIRA, Github Issues, etc.). Here are some general tips for effective use of each type of platform: +![Image description](what-is-a-contributor.png) -#### Messaging +成功的社区由积极进取的人提供动力——他们并不总是严格由金钱驱动——同行认可和地位通常是开源中的强大力量。 -* Most messages/communications are in English -* Feedback is likely to come in short/focused bursts -* Try not to take criticisms of code personally, but accept good suggestions and rework your code -* If you are reviewing code, critique the code/idea, but don’t criticize the person -* Be aware of timezones, and don’t necessarily expect an immediate response -* Try to ‘show your work’ if asking a question so that the community can point you in the right direction +### 4.6.3 社区需要培育 -#### Bug/Issue Tracking +社区参与是一个循环——期待变化并准备好定期帮助引入新成员。 -* Keep bug reports concise but thorough -* Check the bug/issue system to see if what you’re reporting is already there -* Give enough relevant information, including any test code which triggers the bug -* Understand that there is no community obligation to fix a bug - be prepared for the fact that you might need to fix it yourself -* Give any relevant updates to information if you fix the bug or find a workaround +### 4.6.4 谦虚但大胆 -### Top Four Things to Remember +开源领域的领导力是赢来的，而不是授予的，你工作的组织及其声誉不一定会赋予你在特定项目中的影响力。 -There are a lot of things to consider when you first start working with an open source community. However, if you keep the following four things in mind, they should cover most situations: +重要的是要记住领导力和控制力之间存在很大差异。 大多数开源社区都会拒绝过度控制项目方向的尝试，但希望参与者在获得领导权之前做出有价值的贡献。 -#### Understand Community Governance +![Image description](humble-but-bold.png) -Each community is different, but all of your ‘patches’ need to fit within the overall whole. +在大胆和积极参与之间取得适当的平衡，同时谦虚地接受反馈和返工您的代码贡献需要时间和练习，但牢记这种平衡有助于指导您朝着正确的方向前进。 -#### Understand Community Motivations +# 5. 持续集成和测试的作用 -![what-is-a-contributor](what-is-a-contributor.png) +## 5.1 简介 -Successful communities are powered by motivated people - and they are not always motivated strictly by money - peer recognition and status are often powerful forces in open source. +在本节中，我们将讨论持续集成、测试和部署在开源中的作用，包括与这一关键概念相关的工具、最佳实践和成本。 -#### Communities Need Nurturing +## 5.2 学习目标 -Community participation is a cycle - expect change and be prepared to help bring in new members periodically. +在本节结束时，您应该能够： -#### Be Humble But Bold +- 描述持续集成、测试和部署 +- 描述一些用于实施这些实践的不同工具 +- 阐明实施这些概念的成本和收益 -Leadership in open source is earned, not granted, and the organization you work for and their reputation won’t necessarily grant you influence in a particular project. +## 5.3 持续集成、测试和部署在开源中的作用 -It’s critical to remember that there is a big difference between Leadership and Control. Most open source communities will balk at attempts to overly control the project direction, but expect that participants will make valuable contributions before earning the right to lead. +### 5.3.1 为什么要持续集成？ -![humble-but-bold](humble-but-bold.png) +曾几何时，大多数软件是由相对较小的开发人员团队编写的，他们通常在同一地点工作并经常联系。协调和责任分工可以以一种直接的方式进行。 -Striking the right balance between being bold and participating actively while being humble enough to take feedback and rework your code contributions takes time and practice, but keeping this balance in mind helps guide you in the right direction. +很久以前就开发了修订控制系统，以适应一个项目的多个贡献者。通常有一个存储项目的主副本的存储库，一个或多个开发人员拥有进行更改然后签入的能力。 -# The Role of Continuous Integration & Testing +当有许多开发人员在许多不同的地点在一个具有许多子系统的项目上工作时，事情会变得更加复杂。 Linux 内核是第一个真正庞大的分布式开发项目，它的创建者 Linus Torvalds 发明了 git** ** 系统来合理化分布式开发。 +然而，修订控制系统并不能解决确保不同的贡献者群体正在做的事情实际上协同工作的问题。一组新代码或错误修复不会与另一组冲突。这只能通过测试来完成。 -## Lesson: Introduction +甚至测试也需要多个步骤，例如： +- 是否可以同时应用重叠的更改集，或者它们是否会发生冲突（一个好的修订控制系统，如 git 可以处理大部分工作，但它仍然经常需要人工干预）。 +- 应用所有更改后，项目甚至可以编译吗？例如，一个补丁集可能会删除另一个需要的头文件。这不会被版本控制系统接收到。 +- 它适用于所有可能的目标吗？这可能意味着不同的硬件（例如 x86 与 ARM）或不同的操作系统（例如 Linux 与 MacOS 或 Windows）或不同的库、语言或实用程序版本。 +- 工作是什么意思？是否有非平凡的测试套件可以锻炼具有代表性的工作量，足以让人们相信一切都很好？ -### Section Overview + **持续集成技术** 确保测试如此频繁，以至于任何问题都不会持续很长时间，这有助于分布式开发人员保持一致。 -### In this section, we will discuss the role of continuous integration, testing, and deployment in open source, including tools, best practices, and costs associated with this critical concept. +项目快速和实时地（通常每天多次）吸收变化，运行自动化测试以确保事情协调一致。 一般来说，这个过程是这样的： -### Learning Objectives +![Image description](continuous-integration.png) -By the end of this section, you should be able to: +### 5.3.2 持续交付和持续部署 -* Describe continuous integration, testing, and deployment -* Describe some of the different tools used to implement these practices -* Articulate the costs and benefits of implementing these concepts +持续交付和持续部署的整个过程可以划分为三个独立的步骤或阶段： -### Lesson: The Role of Continuous Integration, Testing, and Deployment in Open Source +- **持续集成** -### Why Continuous Integration? +更改将尽可能多地合并到主分支（“master”）中。自动构建** ** 在尽可能多的软件和硬件变体上运行。冲突一出现就解决。 -Once upon a time, most software was written by a relatively small group of developers, often working in the same location and in frequent contact. Coordination and division of responsibilities could be done in a straightforward manner. +- **持续测试/交付** -Revision control systems **were developed long ago to accommodate more than one contributor working on a project. Usually there is a repository** which stores the master copy of a project, with one or more developers possessing the ability to make changes and then check them in. +发布过程是自动化的，项目已准备好交付给构建的使用者。在所有相关平台上都进行了彻底的测试。 -Things get more complicated when there are many developers working in many different locations on a project with many subsystems. The Linux kernel was the first really huge distributed development project, and its creator, Linus Torvalds, invented the **git** system for rationalizing distributed development. +- **持续部署** -However, a revision control system does not solve the problem of making sure what a diverse group of contributors is doing actually works together; that one set of new code or bug fixes does not conflict with another. That can only be done by testing. +产品再次以自动化方式发布给客户。 -Even the testing requires multiple steps such as: +这些步骤之间的时间间隔应尽可能接近于零。在一个完美的世界中，开发人员的更改可以在同一天甚至几分钟内到达最终用户客户。这些术语的定义可能有所不同；例如，可以认为持续集成包括交付和部署。 +- **持续测试** -* Can overlapping sets of changes be applied simultaneously, or do they conflict (a good revision control system such as **git** can handle most of this work, but it still often requires human intervention). -* When all changes are applied does the project even compile? For example, one patch set might remove a header file that another one needs. This does not get picked up by the revision control system. -* Does it work on all possible targets? That might mean differing hardware (say **x86 vs ARM**) or different operating systems (say **Linux vs MacOS or Windows**) or different library, language or utility versions. -* What does **working** mean? Are there non-trivial test suites that can exercise a representative workload enough to give confidence things are fine? +持续交付和部署周期的一个关键组成部分是在开源代码库上频繁运行的自动化和持续测试。 重叠测试周期的概念用于确保通过持续集成（请记住，在小的更改集中）集成的代码经过彻底测试，并且很容易发现潜在问题。 一个示例可能如下所示： -**Continuous Integration** techniques ensure that testing is so frequent that any problems can not persist for long, which helps distributed developers stay on the same page. +![Image description](overlapping-test-cycles.png) -Projects absorb changes rapidly and in real time (multiple times per day usually) run automated tests to make sure things are in harmony. In general, the process looks like this: +开源项目的重叠发布周期使其能够经常发布，同时对整体软件质量保持更严格的控制： -![continuous-integration](continuous-integration.png) +![Image description](overlapping-release-cycles.png) -### Continuous Delivery and Continuous Deployment +### 5.3.3 成本和收益 -The whole process of continuous delivery and continuous deployment can be delineated as three separate steps, or stages: +显然，软件开发中没有免费的东西，因此考虑持续交付和部署所涉及的成本和收益非常重要。以下是一些成本和收益的示例： -1. **Continuous Integration** +- **费用** -Changes are to be merged into the main branch (“master”) as often as possible. **Automated builds** are run on as many variations of software and hardware as possible. Conflicts are resolved as soon as they arise. +- 必须经常合并更改，可能至少每天一次，这可能会给开发人员带来压力。 +- 存储库必须由持续集成服务器监控** **每次做出贡献时都会运行脚本化的自动化测试。必须分配工作人员来做到这一点。 +- 必须运行脚本和其他工具来执行自动化测试并报告其结果并采取适当的措施。准备这个基础设施可能需要很多工作。 -2. **Continuous Testing/Delivery** +- **好处** -The release process is automated and projects are ready to be delivered to consumers of the build. Thorough testing is done on all relevant platforms. +- 开发人员不会走错路并复合可修复的错误，也不会妨碍对方，这最终节省了宝贵的时间。 +- 构建步骤是完全自动化的，所有工作都预先完成，而不是每次都需要完成构建测试。 +- 回归（破坏工作产品的错误）可以被最小化，这意味着发布的软件应该有更少的错误。 +- 设置持续集成管道并非易事，需要相当多的经验和努力才能做好。但是“一盎司的预防胜过一磅的治疗。”有许多现有的工具和服务可以帮助减轻工作的艰巨性。 -3. **Continuous Deployment** +### 5.3.4 工具 -The product is released to customers, once again in an automated fashion. +有许多完善的持续集成软件工具。 有关此类产品的摘要，请参阅 https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/。 请注意，其中一些是免费工具，而另一些则不是。 -The time gap between these steps is meant to be as close to zero as possible. In a perfect world, developer changes can reach end user customers the same day or even in minutes. These terms can be defined somewhat differently; for example, continuous integration can be considered to include both delivery and deployment. +以下是一些最常用的工具： -### Continuous Testing +- Jenkins - https://jenkins-ci.org +- Circle CI - https://circleci.com/ +- Travis - https://travis-ci.org/ +- Github Integrity - http://integrity.github.io/ -A key component of the continuous delivery and deployment cycle is automated and continuous tests that are run frequently on the open source code base. The concept of overlapping test cycles is used to make sure that code being integrated through continuous integration (remember, in small change sets) is thoroughly tested and it’s easy to spot potential issues. An example might look like this: +要记住的一件事是，总是有新的工具正在开发中，因此最好检查一下 -![overlapping-test-cycles](overlapping-test-cycles.png) +Google 和/或与其他开发人员讨论他们正在使用哪些工具进行持续集成。 -The overlapping release cycles of an open source project give it the ability to release often while keeping a tighter control on overall software quality: +### 5.3.5 持续交付基金会 -![overlapping-release-cycles](overlapping-release-cycles.png) +跟上持续交付最新动态的另一种方法是查看持续交付基金会 (CDF)，这是 Linux 基金会于 2019 年 3 月宣布的一个项目。它旨在成为供应商中立的合并CI/CD（持续交付和集成）领域中的重要项目。 -### Costs and Benefits +通过建立和记录最佳实践、制定指南和提供培训，目标是宣传和传播 CI/CD 和 DevOps 实践并改进产品发布流程。 -Obviously, nothing comes for free in software development, so it’s important to consider the costs and benefits involved with continuous delivery and deployment. Below are some of the examples of both cost and benefits: +**创始项目**是： -#### Costs +- Jenkins：一个 OSS CI/CD 系统 +- Jenkins X：用于 Kubernetes 的 Jenkins +- Spinnaker：OSS 多云 CD 平台 +- Tekton：CI/CD 组件的 OSS 规范 -* Changes have to be merged very often, probably at least once a day, putting a possible strain on developers. -* The repository must be monitored by **a continuous integration server**, which runs scripted automation tests every time contributions are made. Staff has to be allocated to do this. -* Scripts and other tools have to be run to perform automated tests and report their results and take appropriate actions. It can be a lot of work to prepare this infrastructure. +该基金会的 TOC（技术监督委员会）有一个开放的治理模式，欢迎贡献。 -#### Benefits +该倡议的创始成员包括： -* Developers do not go down the wrong path and compound fixable mistakes, or get in each other’s way, which in the end saves valuable time. -* The build steps are fully automated, all the work has been done up front instead of each time build testing needs to be done. -* Regressions (bugs which break working products) may be minimized, which means that released software should have fewer bugs. +Alauda、阿里巴巴、Anchore、Armory.io、Atos、Autodesk、Capital One、CircleCI、CloudBees、DeployHub、GitLab、谷歌、汇丰银行、华为、IBM、JFrog、Netflix、Puppet、Rancher、Red Hat、SAP、Snyk 和 SumoLogic . -Setting up a continuous integration pipeline is not trivial and can take quite a bit of experience and effort to get right. But “an ounce of prevention is worth a pound of cure.” There are many existing tools and services that can help make the work less daunting. +了解如何参与，或在 https://cd.foundation 上关注基金会的进展。 -### Tools +# 6. 在内部应用开源方法 -There are many well developed continuous integration software tools. For a summary of such products, see [https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/](https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/). Note that some of these are free tools and some are not. +## 6.1 介绍 +在本节中，我们将提供有关如何将开源原则应用于内部或通常“封闭”的开发工作的信息，这个过程称为“内部源代码”。我们将介绍实施这种做法的实际原因，以及它如何 可以通过支持与外部受众更好的开源参与来使您的组织受益。 -Here are some of the most often utilized tools: +## 6.2 学习目标 -* Jenkins - [https://jenkins-ci.org](https://jenkins-ci.org) -* Circle CI - [https://circleci.com/](https://circleci.com/docs/skip-a-build) -* Travis - [https://travis-ci.org/](https://travis-ci.org/) -* Github Integrity - [http://integrity.github.io/](http://integrity.github.io/) +在本节结束时，您应该能够： -One thing to keep in mind is that there are always new tools being developed, so it’s a good idea to check Google and/or discuss with other developers what tools for continuous integration they are using. +- 描述什么是内部源代码以及它如何用于改进内部项目以及外部开源参与。 +- 解释在您的组织中实施内部源实践可以采取的一些实际步骤。 -### The Continuous Delivery Foundation +## 6.3 为什么是内源？ -Another way of keeping up with the latest in continuous delivery is to take a look at the **Continuous Delivery Foundation (CDF)**, a project announced by the **Linux Foundation** in March 2019. It is designed to be a vendor-neutral home for the coalescence of significant projects in the CI/CD (continuous delivery and integration) universe. +### 6.3.1 什么是内源？ -By establishing and documenting best practices, working out guidelines and making training available, the goal is to evangelize and spread CI/CD and DevOps practices and improve product release processes. +根据维基百科，内部源被定义为：“使用开源软件开发最佳实践，并在组织内建立类似开源的文化。 该组织可能仍然开发闭源软件，但在内部开放其开发。 这个词是 Tim O'Reilly 在 2000 年创造的。” -**The founding projects** are: +重要的是要注意这个定义中类似开源的文化部分。 简单地采用开源开发实践（正如我们在本培训中所描述的）仍然会在内部使您的开发过程受益，但要实现 Inner Source 的全部好处，在您的开发组织内部建立更加开放和透明的文化非常重要（ 并支持法律、财务、人力资源和管理等组织）。 -* **Jenkins**: an OSS CI/CD system -* **Jenkins X**: Jenkins for Kubernetes -* **Spinnaker**: an OSS multicloud CD platform -* **Tekton**: an OSS specification for CI/CD components +### 6.3.2 为什么是内源？ -This Foundation’s **TOC** (Technical Oversight Committee) has an open governance model that welcomes contributions. +内源原则对内部开发有意义的原因有很多，我们将在下面列出一些最重要的： -Founding members of this initiative include: +- **The list** 更高效更有效的开发 -**Alauda, Alibaba, Anchore, Armory.io, Atos, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, HSBC, Huawei, IBM, JFrog, Netflix, Puppet, Rancher, Red Hat, SAP, Snyk, and SumoLogic**. + - 更快的上市时间 + - 通过软件重用降低开发成本 -See how you can get involved, or just follow the foundation's progress at https://cd.foundation. +- **The list** 更好的跨组织协作 -# Applying Open Source Methodologies Internally + - 组织单位之间的成本和风险分担 + - 全计划信息交流 -## Lesson: Introduction +- **更成功的软件重用** -### Section Overview + - 使用组件供应商缺少的能力 + - 减轻组件供应商的负担 -In this section, we will provide information on how to apply open source principles to internal or normally ‘closed’ development efforts, a process called ‘Inner Source.’ We’ll cover the practical reasons for implementing this practice, as well as how it can benefit your organization by supporting better open source engagement with external audiences. +- **加强知识共享** -### Learning Objectives + - 基于社区的学习 + - 知识的开放性和可用性 -By the end of this section, you should be able to: +- **更好地参与外部开源** -* Describe what Inner Source is and how it's useful for improving internal projects as well as external open source engagement. -* Explain some practical steps that can be taken to implement Inner Source practices in your organization. + - 开发人员不必在内部和开源开发实践之间进行上下文切换 + - 开源开发人员的招聘/入职变得更容易 -## Lesson: Why Inner Source? +我们接下来将介绍传统和内部源代码开发实践之间的一些主要区别，根据我们在本模块中迄今为止所涵盖的内容，其中一些应该已经很熟悉了。我们还将尝试提供一些有关如何在您的组织中实施这些实践的实用技巧。 -### What is Inner Source? +## 6.4 内在源头的沟通 -According to [Wikipedia](https://en.wikipedia.org/wiki/Inner_source), Inner Source is defined as: “The use of [open source](https://en.wikipedia.org/wiki/Open-source_software) [software development](https://en.wikipedia.org/wiki/Software_development) best practices and the establishment of an [open source-like culture](https://en.wikipedia.org/wiki/Open-source_model) within organizations. The organization may still develop closed source[ software](https://en.wikipedia.org/wiki/Proprietary_software), but internally opens up its development. The term was coined by [Tim O'Reilly](https://en.wikipedia.org/wiki/Tim_O%27Reilly) in 2000.” +正如我们在本模块前面介绍的那样，透明通信对于开源项目的成功至关重要，它们对于内部源代码同样重要。 -It’s important to note the open source-like culture piece of this definition. Simply adopting open source development practices (as we’ve described in this training) will still benefit your development process internally, but to achieve the full benefit of Inner Source, it’s important to build a more open and transparent culture internally within your development organization (and support orgs like Legal, Finance, HR and management). +它们也往往是面临最大文化挑战的领域，因为私人电子邮件、面对面会议和私人电话会议通常是大多数内部开发项目的常态。使用 IRC、Slack 和透明论坛等异步工具开放您的内部沟通实践，不仅可以帮助促进跨项目协作，还可以让您的组织准备好在外部开源项目中更有效地工作。 -### Why Inner Source? +无论您选择什么工具（即使它是电子邮件别名），请确保有可用的开放档案，并且在公开讨论有关项目方向的决策，以便将项目决策记录在每个人都可以访问的地方。 -There are many reasons why Inner Source principles makes sense for internal development, and we’ll list some of the most important below: +### 6.4.1 开放参与内在源头 -**More efficient and effective development** +与通常由核心团队在封闭存储库中完成的传统内部开发不同，根据定义，内部源项目需要在开放环境中构建。这不仅意味着如上所述的开放交流，还意味着开放的软件存储库、已发布的路线图和文档，以及简单的“入口”和清晰的贡献治理模型。 -* Faster Time-to-Market -* Reduced development costs through software reuse +此外，清晰透明的错误和问题跟踪是必须的。许多团队发现，不属于核心团队的开发人员和用户的这种公开参与是内部源代码最具挑战性的方面，因为它使您的项目和代码接受外部审查。然而，这样做的积极一面是，它迫使您编写更好的代码、更清晰的文档，并从外部角度思考您的架构。 -**Better cross-organizational collaboration** +### 6.4.2 内源同行评审 -* Cost and risk sharing among organizational units -* Program-wide information exchange +由于内部源实践意味着您涉及不属于核心项目团队的用户，因此同行评审的概念变得非常重要。虽然您可能已经建立了代码审查甚至结对编程的实践，但让“外部”开发人员查看您的代码是完全不同的。 -**More successful software reuse** +他们可能会为项目的代码审查带来新的观点（以及一开始的很多问题）。但是，它们也带来了新资源，您的团队在提交代码之前可能不必执行严格的审查。此外，随着以前的外部贡献者越来越熟悉您的代码库，您的团队也越来越熟悉他们，这有助于建立一个信任和思想交叉传播的网络。 -* Use of competences missing at component providers -* Relief of component providers +### 6.4.3 内部源中的迭代发布 -**Enhanced knowledge sharing** +我们已经在本模块中介绍了开源的迭代性质和“尽早发布，经常发布”的口头禅——这通常与大多数内部开发工作形成直接对比，后者使用固定发布周期和定义的路线图变化很快。 -* Community-based learning -* Openness and availability of knowledge +通过使用更具迭代性或敏捷性的开发方法，并将较小的更改集成到代码库中，您不仅可以更轻松地适应不断变化的需求，还可以防止大量回归或成本高昂的错误，这些错误曾经编入项目架构中很难修复。 -**Better engagement with external open source** +利用本培训中前面提到的持续集成/测试/部署实践，不仅可以让您的内部源项目更有效地工作，而且还可以培训开发团队与使用这种开发风格的外部开源项目合作。 -* Developers don’t have to context-switch between internal and open source development practices -* Recruiting/onboarding of open source developers made easier +### 6.4.4 内源人员配备 -We’ll next cover some of the main differences between traditional and inner source development practices, and some of these should already look familiar based on what we’ve covered so far in this module. We’ll also try to give some practical tips on how to implement these practices in your organization. +Inner Source 的人力资源方面有时在组织中非常具有挑战性，在这些组织中，传统的层次结构或文化将开发人员分配到特定项目，而不允许他们为公司内部的任何其他工作做出贡献。 -### Communication in Inner Source +重要的是要考虑如何激励开发人员参与组织内部的项目并为其做出贡献，他们可能会将这些项目作为其代码库的一部分使用。确保管理团队完全支持并激励他们自己允许这种跨团队协作也很重要。 -As we’ve covered earlier in this module, transparent communications are critical to the success of open source projects, and they are equally as important to inner source. +当然，这里有一个平衡行为，开发人员需要确保他们有效地为他们的核心项目做出贡献，同时找到他们也可以做出有价值贡献的相关项目。出于这个原因，通常最好考虑让项目开发人员为通用基础设施或平台编码做出贡献——我们将稍后介绍。 -They also tend to be the areas that have the greatest cultural challenge, as private emails, face-to-face meetings, and private conference calls are usually the norm in most internal development projects. Opening up your internal communication practices with asynchronous tools like IRC, Slack, and transparent forums can help not only facilitate cross-project collaboration, but it can prepare your organization to work more effectively in external open source projects. +允许这种跨团队协作的一个主要好处是，如果工程师觉得他们可以为自己团队以外的组织做出有价值的贡献，那么开发人员的知识、士气甚至保留率都可以提高。 -Whatever tool you choose (even if it’s an email alias), make sure that there are open archives available and that decisions about the project direction are discussed in the open so that project decisions are recorded in a place that everyone has access to. +### 6.4.5 实施注意事项 -### Open Involvement in Inner Source - -Unlike traditional internal development, which is usually done by a core team in a closed repository, inner source projects by definition need to be built in the open. This means not only open communication, as noted above, but also open software repositories, published roadmaps and documentation, as well as easy ‘onramps’ and a clear governance model for contribution. - -Additionally, clear and transparent bug and issue tracking is a must. Many teams find this open involvement of developers and users who aren’t part of the core team the most challenging aspect to inner source, as it opens up your project and code to outside scrutiny. The positive side of this, however, is that it forces you to write better code, clearer documentation, and to think through your architecture from an outside perspective. - -### Peer Review in Inner Source - -Since inner source practices mean you are involving users who aren’t part of your core project team, the concept of peer review becomes very important. While you may have set up a practice of code review or even pair programming, having ‘external’ developers looking at your code is quite different. - -They are likely to bring fresh perspectives (and a lot of questions at first) to code reviews of the project. However, they also bring fresh resources that your team may not have had to perform rigorous reviews prior to code being committed. Additionally, as previously external contributors become more familiar with your code base, and your team more familiar with them, it helps build a web of trust and cross-pollination of ideas. - -### Iterative Releases in Inner Source - -We’ve covered both the iterative nature and the ‘release early, release often’ mantra of open source in this module - this is usually in direct contrast to most internal development efforts which use a fixed release cycle with a defined roadmap that doesn’t change very quickly. - -By utilizing a more iterative or Agile approach to development, and by integrating smaller changes to the code base, you can not only adapt more easily to changing requirements, you can prevent a lot of regression or costly bugs that once codified in a project’s architecture are difficult to fix. - -Utilizing the practices mentioned earlier in this training for continuous integration/testing/deployment will allow your inner source project to not only work more effectively, but it will also train the development teams to work with external open source projects who utilize this style of development. - -### Staffing in Inner Source - -The human resources aspects of Inner Source are sometimes very challenging in organizations where traditional hierarchies or cultures assign developers to specific projects and don’t allow for them to contribute to any other work inside of the company. - -It’s important to consider how to incentivize developers to participate and contribute to projects inside of the organization that they may consume as part of their codebase. It’s also important to make sure that management teams are fully supportive and themselves incentivized to allow this kind of cross-team collaboration. - -There is, of course, a balancing act in play here, where developers will need to make sure they contribute effectively to their core project, while finding related projects that they can make valuable contributions to as well. For this reason, it’s usually best to consider having project developers contribute to common infrastructure or platform coding - we’ll cover that a little bit more shortly. - -One major benefit that can come from allowing this kind of cross-team collaboration is that developer knowledge, morale, and even retention can improve if engineers feel like they can make valuable contributions to the organization beyond their own team. - -### Implementation Considerations - -All of the suggestions for implementing inner source are possible, but also sometimes extremely challenging in organizations where traditional command and control hierarchies exist. Therefore, it’s often a good idea to start implementing inner source ‘at the edge,’ with small projects that may already have quite a bit of interdependence. - -For example, foundational libraries, platforms or common user-interface components are generally good candidates for these kinds of efforts, but it will still require both cultural change (on both the component teams and teams that consume those components) as well as potential code re-architecting/documentation, cleanup, etc., to allow for successful inner source. - -Try to secure early wins with small projects, and follow the ‘release early, release often’ mantra of evaluating your inner source program to see what needs to be changed as you go along. Most importantly, understand that this process, while incredibly helpful, can take months (if not years) to bear successful fruit - keep at it! +实施内部源的所有建议都是可能的，但有时在存在传统命令和控制层次结构的组织中也极具挑战性。因此，开始实施客栈通常是个好主意. diff --git a/sources/OSPO-101/module4/code-diveded-into-subsystems.png b/sources/OSPO-101/module4/code-diveded-into-subsystems.png new file mode 100644 index 0000000..d90b0e4 Binary files /dev/null and b/sources/OSPO-101/module4/code-diveded-into-subsystems.png differ diff --git a/sources/OSPO-101/module5/README.md b/sources/OSPO-101/module5/README.md index e2c6771..9ac9d9b 100644 --- a/sources/OSPO-101/module5/README.md +++ b/sources/OSPO-101/module5/README.md @@ -1,1233 +1,1211 @@ --- -status: collected +status: translated title: "OSPO 101 Training Modules - Module 5" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module5/README.md --- -# Open Source Licensing and Compliance Basics +# 1. 开源许可和合规基础 -## Lesson: Introduction +## 1.1 课程简介 -### Section Overview +在本节中，我们将解释开源许可证的作用，描述最常见的许可证类型，并就如何为特定情况选择正确的许可证提供指导。 我们还将介绍软件中知识产权和版权的基础知识，因为这些是理解一般许可的关键概念。 -In this section, we'll explain the role of open source licenses, describe the most common types of licenses and give guidance on how to choose the right license for a particular situation. We'll also cover the basics of intellectual property and copyright in software, as these are key concepts to understanding licensing in general. +## 1.2 学习目标 -### Learning Objectives +在本节结束时，您应该能够： -By the end of this section, you should be able to: +- 描述软件中的知识产权和版权以及它们与许可的关系 +- 解释开源许可证，包括当今使用的最常见的许可证类型 +- 阐明在为您的组织和/或项目选择特定许可证时应使用的标准 -- Describe intellectual property and copyright in software and how they relate to licensing -- Explain open source licenses, including the most common types of licenses in use today -- Articulate what criteria you should use when selecting a particular license for your organization and/or project +# 3 知识产权和版权 -## Lesson: Intellectual Property and Copyright +## 3.1 什么是知识产权？ -### What is Intellectual Property? +知识产权是一个核心要素，需要了解它才能围绕开源和其他软件许可类型做出明智的选择。 知识产权分为以下几类： -Intellectual property is a core element that needs to be understood to be able to make intelligent choices around open source and other software license types. There are several categories of Intellectual Property, as listed below: +- 版权：保护作者的原创作品 + - 保护表达（不是潜在的想法） + - 涵盖软件、书籍和类似作品 +- 专利：新颖且非显而易见的有用发明 + - 创建有限的垄断来激励创新 +- 商业秘密：保护有价值的机密信息 +- 商标：保护标识产品来源的标记（文字、标志、标语、颜色等） + - 消费者和品牌保护：有助于避免消费者混淆和品牌稀释 -- **Copyright:** protects original works of authorship - - Protects expression (not the underlying idea) - - Covers software, books, and similar works -- **Patents**: useful inventions that are novel and non-obvious - - Creates a limited monopoly to incentivize innovation -- **Trade secrets**: protects valuable confidential information -- **Trademarks**: protects marks (word, logos, slogans, color, etc.) that identify the source of the product - - Consumer and brand protection; helps avoid consumer confusion and brand dilution +出于本课程的目的，我们将重点关注版权和专利，这两个领域与开源许可合规性最相关。 -For our purposes in this course we'll focus on copyright and patents, the areas most relevant to Open Source license compliance. +## 3.2 软件中的一般版权概念 -### General Copyright Concepts in Software +版权是告知开源许可合规性的两个关键要素之一（另一个是专利）。 以下是版权的一些基本要素： -Copyright is one of the two critical elements (patents is the other) that inform open source license compliance. Here are some basic elements of copyright: +- 版权保护创意作品，例如书籍、电影、图片、音乐、地图 +- 软件被视为创造性作品并受版权保护 + - 不是功能（受专利保护）而是表达（实施细节中的创造力） + - 这种保护包括二进制或源代码形式的软件 +- 版权所有者只控制他或她创作的作品，而不是其他人的独立创作 +- 未经作者许可转载可能构成侵权 -- Copyright protects creative works such as books, movies, pictures, music, maps -- **Software is considered a creative work and is protected by copyright** - - Not the functionality (that's protected by patents) but the expression (creativity in implementation details) - - This protection includes software in binary or source code form -- The copyright owner only has control over the work that he or she created, not someone else's independent creation -- Infringement may occur if copying without the permission of the author +## 3.3 软件中最相关的版权 -### Most Relevant Copyright Rights in Software +有一些与软件版权相关的重要权利。这些权利的授予方式与许可有关（我们将很快介绍）。具体而言，因司法管辖区而异的相关权利是： -There are some important rights related to copyrights with software. How these rights are granted relates to licenses (which we will cover shortly). Specifically, the relevant rights, which vary by jurisdiction, are: +- 复制软件的权利——制作副本 +- 创作“衍生作品”的权利——进行修改 + - 衍生作品一词来自美国版权法 + - 一般而言，它是指基于原创作品的新作品，并添加了足够的原创作品，因此新作品代表作者的原创作品而不是复制品 +- 分配权 + - 分发通常被视为以二进制或源代码形式向另一个实体（您公司或组织之外的个人或组织）提供一份软件的副本 -- The right to _reproduce_ the software – making copies -- The right to create "_derivative works_" – making modifications - - The term derivative work comes from the US Copyright Act - - In general it refers to a new work based upon an original work to which enough original creative work has been added so that the new work represents an original work of authorship rather than a copy -- The right to _distribute_ - - Distribution is generally viewed as the provision of a copy of a piece of software, in binary or source code form, to another entity (an individual or organization outside your company or organization) +重要的是要注意，对什么构成“衍生作品”或“发行版”的解释在开源社区和开源法律圈内存在争议，因此这是一个会随着时间不断发展的领域。 -_It's important to note here that the interpretation of what constitutes a "derivative work" or a “distribution” is subject to debate in the Open Source community and within Open Source legal circles, so this is an area that will continue to evolve over time._ +## 3.4 软件专利概念 -### Patent Concepts in Software +专利也是一个重要的领域，可以对开源合规性产生重大影响（取决于许可证类型，我们稍后也会介绍）。 -Patents are also an important area that can have a significant bearing on open source compliance (depending on license type, which we will also cover a bit later). +专利的一些关键要素包括： -Some critical elements of patents include: +- 专利保护功能——这可以包括操作方法，例如计算机程序 +- 他们不保护抽象的想法或自然法则 +- 专利申请必须在特定司法管辖区提出，才能在该国获得专利。 如果专利被授予，所有者有权阻止任何人行使其功能，无论是独立创造的 +- 希望使用该技术的其他方可能会寻求专利许可（可能授予使用、制造、制造、销售、要约销售和进口该技术的权利） -- Patents protect functionality – this can include a method of operation, such as a computer program - - They do not protect abstract ideas, or laws of nature -- A patent application must be made in a specific jurisdiction in order to obtain a patent in that country. If a patent is awarded, the owner has the right to stop anybody from exercising its functionality, regardless of independent creation -- Other parties who want to use the technology may seek a patent license (which may grant rights to use, make, have made, sell, offer for sale, and import the technology) +需要注意的是，即使其他方独立创造了相同的发明或软件，也可能发生专利侵权。 -It's critical to note that patent infringement may occur even if other parties independently create the same invention or software. +## 3.5 许可证基础知识 -### License Basics +虽然我们将很快介绍许可证的更详细方面，但重要的是对许可证的作用和提供的内容有一些基本的了解。 -While we will cover more detailed aspects of licenses shortly, it's important to have some basic understanding of what licenses do and what they provide. +- “许可”是版权或专利持有人向他人授予许可或权利的方式 +- 许可证可以限于： + - 允许的使用类型（商业/非商业、分销、衍生作品/制作、已制作、制造） + - 排他性或非排他性条款 + - 地理范围 + - 永久或限时 +- 许可证可以对赠款设置条件，这意味着您只有在遵守某些义务的情况下才能获得许可证 + - 例如，提供归属，或给予互惠许可 +- 还可能包括有关保修、赔偿、支持、升级、维护的合同条款 -- A "license" is the way a copyright or patent holder gives permission or rights to someone else -- The license can be limited to: - - Types of use allowed (commercial / non-commercial, distribution, derivative works / to make, have made, manufacture) - - Exclusive or non-exclusive terms - - Geographical scope - - Perpetual or time limited duration -- The license can have conditions on the grants, meaning you only get the license if you comply with certain obligations - - E.g, provide attribution, or give a reciprocal license -- May also include contractual terms regarding warranties, indemnification, support, upgrade, maintenance +# 4. 开源许可证类型 -## Lesson: Open Source License Types +## 4.1 总体许可证类别 -### Overall License Categories +有了前面几页的信息，您应该对许可证的用途有了基本的了解。 让我们来看看下面的整体许可证格局（包括闭源许可证）： -Armed with the information from the preceding pages, you should have a basic understanding of what licenses are used for. Let's take a look at the overall license landscape (including closed source licenses) below: +![Image description](license-categories.png) -![Open Source/Free Software and Closed Source Software Licenses](license-categories.png) +此图提供了开源和闭源许可证的一般概述。 虽然我们很快将深入研究开源许可证类型的更多细节，但最好了解一下普遍可用的不同类型的许可证。 -This diagram gives a general overview of both Open Source and Closed Source licenses. While we will dive into more detail on the open source licenses types shortly, it's good to get a perspective of the different types of licenses generally available. +在开源方面，许可证通常分为两大类： -On the open source side, licenses generally fall into two main categories: +**宽容的** -**Permissive** +这些许可证只对重新发布软件时必须做的事情施加了最低限度的要求。这些需求通常仅限于保留或交付属性通知之类的事情。 -These licenses only impose minimal requirements on what you must do when redistributing the software. Those requirements are typically limited to things like retaining or delivering attribution notices. +**CopyLeft/互惠** -**Copyleft/Reciprocal** +Copyleft许可有时被称为保护许可或互惠许可。他们有关于如何重新分发软件的需求，以及可能影响如何分发派生工作的需求，例如要求发布您可能对软件进行的所有更改/增强。 -Copyleft licenses are sometimes called protective or reciprocal licenses. They have requirements for how the software can be redistributed, as well as requirements that may impact how derivative works can be distributed, such as requiring release of all changes/enhancements you may make to the software. +开源计划(https://opensource.org/)是一个重要的书签资源，该组织负责跟踪和审查已批准的开源许可。在他们的网站上有更多关于开源许可的定义和类型的细节。 -An important resource to bookmark is the Open Source Initiative ([https://opensource.org/](https://opensource.org/)), the organization responsible for tracking and vetting approved open source licenses. There is a lot more detail in their website about the definition and types of open source licenses. +## 4.2 宽松的开源许可证 -### Permissive Open Source Licenses +如前所述，如果您进行更改和重新分发软件，宽松许可证通常对您必须执行的操作的限制最少。 出于这个原因，它们通常（但不总是）在公司内部预先批准的列表中，指定组织中的工程师可以使用哪些开源软件许可证类型。 -As mentioned earlier, permissive licenses generally have the least amount of restrictions on what you must do if you make changes and redistribute the software. For that reason, they are generally (but not always) on pre-approved lists within companies that specify what open source software license types can be consumed by engineers in the organization. +让我们以 BSD-3-Clause 许可证为例。 本许可是一个许可许可的例子，它允许出于任何目的以源代码或目标代码形式无限制地重新分发更改，只要维护其版权声明和许可的免责声明即可。 -Let's take the example of the BSD-3-Clause license. This license is an example of a permissive license that allows unlimited redistribution of changes for any purpose in source or object code form as long as its copyright notices and the license's disclaimers of warranty are maintained. +但是，该许可证包含一个条款，限制在未经特别许可的情况下使用贡献者的姓名为衍生作品背书。 -However, the license contains a clause restricting use of the names of contributors for endorsement of a derived work without specific permission. +其他许可许可的例子包括：MIT、Apache-2.0。 -Other examples of permissive licenses include: MIT, Apache-2.0. +## 4.3 Copyleft/互惠许可 -### Copyleft/Reciprocal Licenses +某些许可证要求如果分发衍生作品（或同一文件、同一程序或其他边界中的软件），则该分发与原始作品的条款相同。 -Some licenses require that if derivative works (or software in the same file, same program or other boundary) are distributed, the distribution is under the same terms as the original work. +这被称为“左版”或“互惠”效应，如果您的衍生作品是用于为您的公司提供独特优势的高度专有软件，则可能会产生重要后果。在某些情况下，这可能需要您将与开源软件结合的专有作品的源代码发布给您向其分发作品的编译版本或二进制版本的任何人。 -This is referred to as a "copyleft" or “reciprocal” effect and can have important consequences if your derivative work is, for example, a highly proprietary piece of software used to provide a unique advantage for your company. In some cases, this could require you to release the source code of a proprietary work that is combined with open source software to anyone to whom you distribute the compiled or binary version of the work. +以下是 GPL 2.0 版的许可互惠示例： -Here is an example of license reciprocity from the GPL version 2.0: +> 您必须根据本许可的条款使您分发或发布的任何作品（全部或部分包含或源自程序或其任何部分）获得许可 […]。 -> You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed […] under the terms of this License. +其他包含互惠或 Copyleft 条款的许可包括 GPL、LGPL、AGPL、MPL 和 CDDL 的所有版本。您可以在 https://opensource.org/licenses 上查看更多详细信息。 -Other licenses that include reciprocity or Copyleft clauses include all versions of the GPL, LGPL, AGPL, MPL and CDDL. You can see more details for these at [https://opensource.org/licenses](https://opensource.org/licenses). +## 4.4 许可证兼容性 -### License Compatibility +许可兼容性是确保许可条款不发生冲突的过程，这可能会变得特别具有挑战性，因为许多软件（包括内部开发的软件）可能会相互构建并由具有不同许可的软件构建而成类型。 -License compatibility is the process of ensuring that license terms do not conflict, and this can get particularly challenging as many pieces of software, including ones that are internally developed, are likely to build on each other and be built from pieces of software with different license types. +以下是一些示例： -Here are some examples: +- 如果一个许可证要求您做某事而另一个许可证禁止您这样做，则如果两个软件模块的组合触发了两个许可证下的义务，则许可证会发生冲突并且不兼容。 + - GPL-2.0 和 EPL-1.0 各自将其义务扩展到已分发的“衍生作品”。 + - 如果 GPL-2.0 模块与 EPL-1.0 模块组合并且合并的模块是分布式的，则该模块必须 + - （根据 GPL-2.0）仅在 GPL-2.0 下分发，并且 + - （根据 EPL-1.0）仅在 EPL-1.0 下分发。 -- If one license requires you to do something and another prohibits doing that, the licenses conflict and are not compatible if the combination of the two software modules trigger the obligations under both licenses. - - GPL-2.0 and EPL-1.0 each extend their obligations to "derivative works" which are distributed. - - If a GPL-2.0 module is combined with an EPL-1.0 module and the merged module is distributed, that module must - - (according to GPL-2.0) be distributed under GPL-2.0 only, and - - (according to EPL-1.0) be distributed under EPL-1.0 only. +在这种情况下，分发者无法同时满足这两个条件，因此模块可能不会分发，从而造成许可证不兼容的示例。 -In this case, the distributor cannot satisfy both conditions at once so the module may not be distributed, creating an example of _license incompatibility._ +请记住，“衍生作​​品”的定义受开源社区的不同观点的影响，其在法律上的解释可能因司法管辖区而异，因此重要的是您要检查适当的资源以针对您的特定情况做出决定案例。 -Remember that the definition of "derivative work" is subject to different views in the Open Source community and its interpretation in law is likely to vary from jurisdiction to jurisdiction, so it's important that you check with the appropriate resources to make that determination for your particular case. +## 4.5 通知 -### Notices +通知（例如文件标题中注释中的文本）通常提供作者身份和许可信息。 开源许可证还可能要求在源代码或文档中或旁边放置通知，以表明作者（归属）或明确软件包含修改。 -Notices, such as text in comments in file headers, often provide authorship and licensing information. Open Source licenses may also require the placement of notices in or alongside source code or documentation to give credit to the author (an attribution) or to make it clear the software includes modifications. +例如： -For example: +- 版权声明 – 放置在作品副本上的标识符，用于告知世界版权所有权。 示例： 版权所有 © A. Person (2020) +- 许可通知 – 指定并承认产品中包含的开源许可条款和条件的通知。 +- 归属通知 – 产品发布中包含的通知，确认产品中包含的开源的原始作者和/或赞助商的身份。 +- 修改通知 – 您对文件的源代码进行了修改的通知，例如将您的版权通知添加到文件顶部。 -- **Copyright notice** – an identifier placed on copies of the work to inform the world of copyright ownership. Example: `Copyright © A. Person (2020)` -- **License notice** – a notice that specifies and acknowledges the license terms and conditions of the Open Source included in the product. -- **Attribution notice** – a notice included in the product release that acknowledges the identity of the original authors and / or sponsors of the Open Source included in the product. -- **Modification notice** – a notice that you have made modifications to the source code of a file, such as adding your copyright notice to the top of the file. +## 4.6 多重许可 -### Multi-licensing +在某些情况下，版权所有者可能会选择在多个许可下提供代码，这种做法被称为“多重许可”。 -There are some cases where a copyright owner may choose to offer the code under multiple licenses, a practice referred to as "multi-licensing." +例如，软件可以是“双重许可”，版权所有者可以让每个接收者选择两个许可。 -As an example, software could be "dual licensed," with the copyright owner giving each recipient the choice of two licenses. +重要的是要注意，对于许可方强加多个许可的情况，不应混淆这一点，并且您必须遵守所有许可。 -It's important to note that this should not be confused for situations in which a licensor imposes more than one license, and you must comply with _all_ of them. +# 5. 选择正确的许可证 -## Lesson: Choosing the Right License +## 5.1 概述 -### Overview +有了到目前为止提供的所有信息，弄清楚如何为您希望在组织中使用的开源代码选择正确的许可证，最终贡献功能或更改，或者创建一个全新的开放源代码似乎令人生畏。 自己的源项目。 -With all of the information presented so far, it might seem daunting to figure out how to choose the right license for open source code that you want to consume in your organization, eventually contribute back features or changes to, or to create a brand new open source project of your own. +值得庆幸的是，有一些常见的问题需要询问和遵循的流程，以帮助您做出明智的选择。 以下是一般概述： -Thankfully, there are some common questions to ask and processes to follow to help you make an informed choice. Here's a general overview: +![Image description](questions.png) -![Questions to Ask](questions.png) +在对现有项目做出贡献时，除非该项目使用具有不同入站许可证的贡献机制，否则通常的做法是根据整个项目所受的许可证条款做出贡献。 -When contributing to an existing project, unless the project uses a contribution mechanism with a different inbound license, the common practice is to make your contributions under the terms of the license the project as a whole is governed by. +在参与或创建新项目时，明确要求使用代码的人（必须）做什么、允许做什么（可以）以及禁止做什么（不能）是非常重要的 . 选择的许可证是您指定此信息的方式。 通过选择标准和常用的开源许可证，您可以帮助其他人更轻松地了解他们的权利和义务是什么。 -When contributing to or creating a new project, it is very important to clarify the things that someone using the code is required to do (must), what they are permitted to do (can), and what they are forbidden to do (cannot). The license selected is your way of specifying this information. By choosing a standard and commonly-used open source license, you help to make it easier for everyone else to understand what their rights and obligations are. + **要考虑的属性** -**Properties to Consider** +在选择许可证时，重要的是要明确发布代码的目标。您希望谁（什么类型的人/组织）采用该准则？您想看到人们在重新分发代码时对您的代码所做的任何更改吗？您是否希望其他人能够出售您的代码以获取利润？ -When choosing a license, it is important to be clear on your goals for releasing the code. Who (what types of people/organizations) do you want to adopt the code? Do you want to see any changes people make to your code when they redistribute it? Do you want other people to be able to sell your code for a profit? +您还应该考虑以下常见属性： -You should also consider the following common properties: +- 发布许可、版权声明、更改摘要？ +- 公开源代码？ +- 修改后的工作分配？ +- 转授权？ +- 私人用途还是商业用途？ +- 专利授权？ +- 可以使用商标吗？ +- 代码可以保修吗？ +- 能否承担损害赔偿责任？ +- 许可范围：作为一个整体工作还是只针对特定文件？ -- Publish license, copyright notices, change summaries? -- Disclosing source code? -- Distribution of modified work? -- Sublicensing? -- Private or commercial use? -- Patent grant? -- Able to use trademarks? -- Can code be warrantied? -- Able to hold liable for damages? -- Scope of license: work as a whole or only specific file? +页面上的列表包含一些常见问题，您应该在公开代码之前了解答案，并选择反映您答案的许可证。这有时是一项可怕的任务，但在过去的几年里，已经创建了一些网站来帮助解决这个问题，这些网站列在下一个屏幕上。 -The list on the page contains some common questions you should understand the answer to before making your code public, and choose a license that reflects your answers. This is sometimes a scary task, but in the last couple of years, there have been websites created to help with this, which are listed on the next chapter. +## 5.2 许可证帮助资源 -### License Help Resources +下面是一些流行的网站，它们讨论了在为您的代码或其他创意作品选择许可证时要考虑的许可证类型和属性。 它们的目的是帮助您选择许可证，并解释一些选项背后的更多背景。 -Below are a few popular sites that discuss the types of licenses and properties to consider in selecting a license for your code, or other creative works. Their purpose is to help you choose a license, and explain more of the background behind some of the options. +### 5.2.1 源代码 -**Source Code** +来自开源计划的按类别划分的开源许可证列出了已批准的开源许可证。 -[_Open Source Licenses by Category_](https://opensource.org/licenses/category) from the Open Source Initiative lists the approved open source licenses. +选择开源许可证由 GitHub 赞助。它会引导您了解您必须考虑的属性，帮助您确定哪种许可证有意义。 -[_Choose an Open Source License_](https://choosealicense.com/) is sponsored by GitHub. It walks you through the properties you must consider, helping you decide what license makes sense. +许可证文本有时会被视为“太长，未阅读” - 表示为 TL;DR。 tl;dr Legal 正试图将法律文本澄清为标准属性。网站创建者与志愿律师合作​​，对与特定许可证相关的属性进行分类和颜色编码，以帮助您更轻松地浏览并更好地了解现有许可证。 -License text sometimes gets treated as "too long, didn't read" - denoted TL;DR. [_tl;dr Legal_](https://tldrlegal.com/licenses/browse) is trying to clarify the legal text into standard properties. The website creators work with volunteer lawyers to classify and color code the properties associated with specific licenses to help you navigate easier and better understand the existing licenses. +- 蓝色 - 您必须遵守的规则。 +- 绿色 - 您可以遵循的规则。 +- 红色 - 你不能做的事情。 -- Blue - Rules you must follow. -- Green - Rules you can follow. -- Red - Things you cannot do. +这是理解一些常见许可条款的非常有用的工具。例如，对于 Mozilla Public License version 1.0，您不能追究贡献者的责任，但如果您使用它，则必须包括版权、许可、声明任何更改并披露来源。 -This is a very useful tool for understanding the terms of some of the common licenses. For example, for Mozilla Public License version 1.0, you cannot hold the contributors liable, but if you use it, you must include copyright, license, state any changes, and disclose the source. +来自自由软件基金会的许可和合规实验室的各种许可证和关于它们的评论提供了许多许可证的描述和关于它们的评论。 -[_Various Licenses and Comments About Them_](https://www.gnu.org/licenses/license-list.en.html) from the Free Software Foundation's Licensing and Compliance Lab provides a description of many licenses and comments about them. +### 5.2.2 其他创意作品 -**Other Creative Work** +知识共享许可可帮助您了解图像和文档的许可选项。这方面的一个例子是 CC-BY-SA 4.0 许可证。我们鼓励您单击知识共享站点的链接，并阅读法律代码文件。它指定了与此许可相关的归属、类似共享和其他属性。 -[Creative Commons Licenses](https://creativecommons.org/choose/) help you understand license options for images and documentation. An example of this is the [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/legalcode) license. We encourage you to click the link to the creative commons site, and read the legal code file. It specifies the attribution, share-alike, and other properties associated with this license. +### 5.2.3 其他资源 -**Additional Resources** +此外，您可以查看此在线资源：来自 Jilayne Lovejoy 和 FINOS（金融科技开源基金会）的开源许可证合规手册。该手册提供了“自助服务”信息，以帮助开源软件的用户和再分发者了解遵守各种许可的具体要求。 -In addition, you can take a look at this online resource: [Open Source License Compliance Handbook](https://github.com/finos-osr/OSLC-handbook) from Jilayne Lovejoy and FINOS (The Fintech Open Source Foundation). The handbook provides "self-serve" information to help users and redistributors of open source software understand the specific requirements for complying with various licenses. +SPDX 许可证列表是另一个用于识别许可证的有用资源。它提供了公共分发软件中使用的常见许可证的精选目录。并非所有许可证都必须是开源的；许可证列表表明哪些已被开源计划批准，哪些已被自由软件基金会列为免费/自由。 -The [SPDX License List](https://spdx.org/licenses/) is another useful resource for identifying licenses. It provides a curated catalog of commonly-seen licenses used in publicly-distributed software. Not all of the licenses are necessarily open source; the License List indicates which ones have been approved by the Open Source Initiative and which have been listed as free/libre by the Free Software Foundation. +许可证列表不包括许可证的解释。相反，它在搜索与特定许可证名称或标识符对应的许可证文本时会很有用。许可证列表贡献者还维护许可证文本的版本，其中标记了许可证文本的某些部分，这些部分被认为是可替换的，同时仍然是基本相同的许可证，这在自动检测源代码中的许可证通知时非常有用。 -The License List does not include interpretations of licenses. Rather, it can be useful when searching for the license text that corresponds to a particular license name or identifier. The License List contributors also maintain versions of the license texts with markup for certain sections of the license text that are considered replaceable while still being substantially the same license, which can be useful when automating detection of license notices in source code. +如果您正在寻找有关如何将许可证信息结构化到您的项目中的指南，我们建议您参考欧洲自由软件基金会的 REUSE 软件指南。它们提供了有关如何将标识符和许可证全文添加到项目中的详细示例，以及用于检查是否符合准则的脚本。 -If you are looking for guidelines on how to structure the license information into your project, we recommend you consult the [REUSE Software](https://reuse.software/) guidelines from the Free Software Foundation Europe. They provide detailed examples on how to add identifiers, and the full text of licenses into projects, as well as scripts to check for compliance with the guidelines. +如果您尝试使用不在 SPDX 许可证列表中的许可证，他们也有关于如何记录它以便工具可以找到信息的很好的建议。 -If you're trying to use a license that is not on the SPDX License List, they also have good recommendations on how it should be documented so that tools can find the information. +# 6. 建立有效的合规计划 -# Section: Building an Effective Compliance Program +## 6.1 简介 -## Lesson: Introduction +在本节中，我们将提供有关有效合规计划背景的信息，以及如何建立此类活动并为其配备人员，包括工程领导和法律合作伙伴关系的重要性。 -### Section Overview +## 6.2 学习目标 -In this section, we will provide information on the background of an effective compliance program, and how to build and staff such an activity, including the importance of engineering leadership and legal partnerships. +在本节结束时，您应该能够： -### Learning Objectives +- 描述建立开源合规计划的原因 +- 解释整个合规流程应该如何运作 +- 阐明领导和法律团队在合规框架内的作用 -By the end of this section, you should be able to: +## 6.3 开源合规性简介 -- Describe the reasons for building an open source compliance program -- Explain how the overall process of compliance should work -- Articulate the role of leadership and legal teams within the compliance framework +### 6.3.1 合规目标 -### Lesson: Introduction to Open Source Compliance +虽然“合规”这个词在某些情况下可能看起来霸道或可怕，但在这种情况下，它可以分解为两个非常具体的目标： -### Compliance Goals + - **了解您的义务** -While the word "compliance" may seem overbearing or scary in some cases, in this case, it can be broken down into two very concrete goals: +您应该有一个过程来识别和跟踪软件中存在的开源组件。 -**Know your obligations** + - **满足许可义务** -You should have a process for identifying and tracking Open Source components that are present in your software. +您的流程应该能够处理因您组织的业务实践而产生的开源许可义务。 -**Satisfy license obligations** +虽然这两个目标当然包含了许多细节（稍后会详细介绍），但重要的是要记住，组织围绕合规性的所有流程决策都可以追溯到这两个总体目标。 -Your process should be capable of handling Open Source license obligations that arise from your organization's business practices. +### 6.3.2 义务 -While there are of course many details embodied in these two goals (more on that later), it's important to keep in mind that all of an organization's process decisions around compliance can be traced back to these two overarching goals. +由于合规领域中的义务很重要，因此了解必须满足哪些义务非常关键。 -### Obligations +根据所涉及的开源许可证，您的合规义务可能包括： -Since obligations in the compliance domain are important, it's key to understand what obligations must be satisfied. + - **归属和通知** -Depending on the Open Source license(s) involved, your compliance obligations may consist of: +您可能需要在源代码和/或产品文档或用户界面中提供或保留版权和许可文本，以便下游用户了解软件的来源以及他们在许可下的权利。您可能还需要提供有关修改的通知或许可证的完整副本。 -**Attribution and Notices** +- **源代码可用性** -You may need to provide or retain copyright and license text in the source code and/or product documentation or user interface, so that downstream users know the origin of the software and their rights under the licenses. You may also need to provide notices regarding modifications, or full copies of the license. +您可能需要提供开源软件的源代码、您所做的修改、组合或链接的软件以及控制构建过程的脚本。 -**Source code availability** +- **互惠** -You may need to provide source code for the Open Source software, for modifications you make, for combined or linked software, and scripts that control the build process. +您可能需要在管理开源组件的同一许可下维护修改后的版本或衍生作品。 -**Reciprocity** +- **其他条款** -You may need to maintain modified versions or derivative works under the same license that governs the Open Source component. +开源许可可能会限制版权所有者名称或商标的使用，可能需要修改版本以使用不同的名称以避免混淆，或者可能会因任何违规行为而终止。 -**Other terms** +### 6.3.3 合规问题：分发 -The Open Source license may restrict use of the copyright holder name or trademark, may require modified versions to use a different name to avoid confusion, or may terminate upon any breach. +在许多开源许可案例中，“分发”是触发许可义务的东西。 但分布究竟意味着什么？ 一般而言，“分发”是指向外部实体分发材料。 有时这可能是一个具有挑战性的领域，即使在法律界也是如此，但这里有几个例子： -### Compliance Issues: Distribution +- **分发事件** -"Distribution" is something that triggers license obligations in many open source license cases. But what does distribution mean exactly? In general, "distribution" means dissemination of material to an outside entity. Sometimes this can be a challenging area, even in legal circles, but here are a few examples: + - 下载到用户机器或移动设备的应用程序 + - 下载到用户机器的 JavaScript、Web 客户端或其他代码 + - 对于某些开源许可证，通过计算机网络访问可能是“分发触发器”事件 -**Distribution Events** +一些许可证将触发事件定义为包括允许访问在服务器上运行的软件（例如，如果软件被修改，则所有版本的 Affero GPL）或在“用户通过计算机网络远程与其交互”的情况下。 -- Applications downloaded to a user's machine or mobile device -- JavaScript, web client, or other code that is downloaded to the user's machine -- For some Open Source licenses, access via a computer network can be a "distribution trigger" event +### 6.3.4 合规问题：修改 -Some licenses define the trigger event to include permitting access to software running on a server (e.g., all versions of the [Affero GPL](https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License) if the software is modified) or in the case of "users interacting with it remotely through a computer network." +修改源代码时可能会发生许可义务的另一个主要因素，例如修复您发现的错误或添加新功能。 此外，将开源代码与您自己的代码或什至其他开源组件相结合可能会产生潜在影响。 -### Compliance Issues: Modification +在某些开源许可证下，修改可能会导致分发时承担额外的义务，例如： -Another major element of license obligations can happen when source code is modified, such as for fixing a bug you find or adding a new feature. Additionally, combining open source code with your own code, or even other open source components can have potential impacts. +- 提供修改通知 +- 提供随附的源代码 +- 在管理开源组件的同一许可证下许可修改 -Under some Open Source licenses, modifications may cause additional obligations upon distribution, such as: +在本模块的后面，我们将介绍如何构建适当的流程来跟踪和管理分发和修改事件的结果。 -- Providing notice of modification -- Providing accompanying source code -- Licensing modifications under the same license that governs the Open Source component +### 6.3.5 合规优势 -Later in this module we'll cover how to build the appropriate processes to track and manage the results of distribution and modification events. +重要的是要注意，虽然偶尔会出现与开源合规性相关的挑战，尤其是在修改或分发方面，但正确构建和运行的合规性计划很简单，可为您的组织带来许多好处，例如： -### Compliance Benefits +- 加深对开源的好处及其对您的组织的影响的理解 +- 加深对与使用开源相关的成本和风险的了解 +- 增加对可用开源解决方案的了解 +- 减少和管理侵权风险，增加对开源开发商/所有者许可选择的尊重 +- 培养与开源社区和开源组织的关系 -It's important to note that though there can be occasionally challenging aspects related to open source compliance, especially around modification or distribution, that a properly build and functioning compliance program is straightforward and brings many benefits to your organization such as: +## 6.4 合规管理流程概述 -- Increased understanding of the benefits of Open Source and how it impacts your organization -- Increased understanding of the costs and risks associated with using Open Source -- Increased knowledge of available Open Source solutions -- Reduction and management of infringement risk, increased respect of Open Source developers/owners' licensing choices -- Fostering relationships with the Open Source community and Open Source organizations +### 6.4.1 合规计划的总体结构 -### Lesson: Compliance Management Process Overview +在开源合规性方面取得成功的组织已经制定了他们的政策、流程、培训和工具，以： -### General Structure of Compliance Programs +- 促进在其产品（商业或其他）中有效使用开源 +- 尊重开源开发者/所有者的权利并遵守许可义务 +- 贡献并参与开源社区 -Organizations that have been successful at Open Source compliance have created their policies, processes, training and tools to: +需要注意的是，这些政策、流程、培训和工具需要提供监督，但不能变得霸道，这一点非常重要。理论上，您可以构建世界上最好的开源合规性计划，但如果它对于工程团队来说过于复杂和繁重而无法使用，那么它很可能不会被利用，或者会因团队在该过程中寻找方法而受到严重阻碍。 -- Facilitate effective usage of Open Source in their products (commercial or otherwise) -- Respect Open Source developer/owner rights and comply with license obligations -- Contribute to and participate in Open Source communities +此外，开源合规性计划应根据您自己组织的性质和要求进行定制。每个组织都以不同的方式开发和构建软件，您的组织可能能够遵守其许可义务，而无需遵循此处描述的确切流程集。 -It's very important to note that these policies, processes, training and tools need to provide oversight without becoming overbearing. You can theoretically build the best open source compliance program in the world, but if it's too complicated and burdensome for the engineering teams to utilize, it most likely will not be utilized, or will be severely hampered by teams finding ways around the process. +### 6.4.2 合规实践概述 -Additionally, an Open Source compliance program should be tailored to the nature and requirements of your own organization. Every organization develops and builds software in a different way, and your organization may be able to comply with its license obligations without following the exact set of processes that are described here. +虽然我们很快会详细介绍，但您在构建合规实践时应考虑的主要领域是： -### Compliance Practices Overview +- 识别所有内部和外部软件的来源和许可 +- 在开发过程中跟踪开源软件 +- 执行开源审查并确定许可义务 +- 产品发货时履行许可义务 +- 监督开源合规计划、政策创建和合规决策 +- 培训 -While we will go into more detail shortly, the main areas that you should be considering when building your compliance practices are: +### 6.4.3 开源审查的关键组件 -- Identification of the origin and license of all internal and external software -- Tracking Open Source software within the development process -- Performing Open Source review and identifying license obligations -- Fulfillment of license obligations when product ships -- Oversight for Open Source Compliance Program, creation of policy, and compliance decisions -- Training +开源审查期间的一个重要考虑因素是考虑您计划如何使用相关开源软件组件。 -### Key Components for Open Source Review +常见场景包括： -An important consideration during open source review is considering how you are planning on using the open source software component in question. +- 公司成立 +- 链接 +- 修改 +- 翻译 +- 分布 -Common scenarios include: +我们将在接下来的几页中更详细地介绍这些内容。 -- Incorporation -- Linking -- Modification -- Translation -- Distribution +### 6.4.4 合并 -We'll cover these in more detail in the next several pages. +开发人员可以将开源组件的某些部分复制到软件产品中。 -### Incorporation +有关条款包括: -A developer may copy portions of an Open Source component into your software product. +- 集成 +- 合并 +- 粘贴 +- 适应 +- 插入 -Relevant terms include: +![Image description](incorporation.png) -- Integrating -- Merging -- Pasting -- Adapting -- Inserting -- Embedding +### 6.4.5 链接 -![Incorporation](incorporation.png) +开发人员可以将开源组件与您的软件产品链接或加入。 -### Linking +相关条款包括： -A developer may link or join an Open Source component with your software product. +- 静态/动态链接 +- 配对 +- 结合 +- 利用 +- 包装 +- 建立相互依存关系 -Relevant terms include: +### 6.4.6 修改 -- Static/Dynamic Linking -- Pairing -- Combining -- Utilizing -- Packaging -- Creating interdependency +开发人员可以对开源组件进行更改，包括： -![Linking](linking.png) +- 在开源组件中添加/注入新代码 +- 修复、优化或更改开源组件 +- 删除或移除代码 -### Modification +![Image description](modification.png) -A developer may make changes to an Open Source component, including: +### 6.4.7 转换 -- Adding/injecting new code into the Open Source component -- Fixing, optimizing or making changes to the Open Source component -- Deleting or removing code +开发人员可以将代码从一种状态转换为另一种状态。 -![Modification](modification.png) +例子包括： -### Translation +- 将中文翻译成英文 +- 将 C++ 转换为 Java +- 编译成二进制 -A developer may transform the code from one state to another. +![Image description](translation.png) -Examples include: +### 6.4.8 开发工具的作用 -- Translating Chinese to English -- Converting C++ to Java -- Compiling into binary +除了人类工程师执行其中一些任务之外，重要的是要注意出于合规性目的，一些开发工具也可以在幕后执行这些功能。 -![Translation](translation.png) +例如，一个工具可以将它自己的代码的一部分注入到工具的输出中。 -### The Effect of Development Tools +![Image description](inject-into-output.png) -In addition to human engineers performing some of these tasks, it's important to note for compliance purposes that some development tools also can perform these functions behind the scenes. +### 6.4.9 分发的合规性注意事项 -For example, a tool may inject portions of its own code into output of the tool. +如前所述，重要的是要考虑如何分发特定的开源组件，特别是： -![Inject into Output](inject-into-output.png) +- 谁收到软件？ +- 客户/合作伙伴 +- 社区项目 +- 业务集团内的另一个法人实体（这可以算作分配） +- 交付形式是什么？ +- 源代码交付 +- 二进制交付 +- 预加载到硬件上 -### Compliance Considerations with Distribution +## 6.5 开源审查流程 -As mentioned earlier, it's important to consider how a particular open source component will be distributed, specifically: +### 6.5.1 开源审查基础 -- Who receives the software? - - Customer/Partner - - Community project - - Another legal entity within the business group (this may count as distribution) -- What's the delivery format? - - Source code delivery - - Binary delivery - - Pre-loaded onto hardware +在程序/产品管理和工程师审查了提议的开源组件的实用性和质量后，应启动对与使用所选组件相关的权利和义务的审查。 -### Lesson: Open Source Review Process +开源合规计划的一个关键要素是开源审查流程。 在此过程中，公司可以分析其使用的开源软件并了解其权利和义务。 -### Open Source Review Basics +该过程包括以下步骤： -After Program/Product Management and engineers have reviewed proposed Open Source components for usefulness and quality, a review of the rights and obligations associated with the use of the selected components should be initiated. +- 收集相关资料 +- 分析和理解许可义务 +- 提供符合公司政策和业务目标的指导 -A key element to an Open Source Compliance Program is the _Open Source Review_ process. This process is where a company can analyze the Open Source software it uses and understand its rights and obligations. +### 6.5.2 启动开源审查 -The process includes the following steps: +![Image description](initiate-review.png) -- Gather relevant information -- Analyze and understand license obligations -- Provide guidance compatible with company policy and business objectives +在公司中与开源工作的任何人都应该能够发起开源审查，包括程序或产品经理、工程师和法律团队成员 -### Initiating an Open Source Review +注意：当工程或外部供应商选择新的基于开源的软件时，该过程通常会开始。 -![Initiating an Open Source Review](initiate-review.png) +### 6.5.3 收集组件信息 -Anyone working with Open Source in the company should be able to initiate an Open Source Review, including Program or Product Managers, Engineers, and Legal team members +在分析您的开源使用情况时，您需要收集有关相关组件的身份、来源以及组件的使用方式的信息。 这些信息可能包括： -_Note: The process often starts when new Open Source-based software is selected by engineering or outside vendors._ +- 包名 +- 包周围社区的状态（活动、多样化的成员、响应能力） +- 版本 +- 下载或源代码地址 +- 版权所有者 +- 许可证和许可证 URL +- 归属和其他通知和 URL +- 拟进行修改的说明 +- 依赖列表 +- 在您的产品中的预期用途 +- 将包含该软件包的第一个产品版本 +- 将维护源代码的位置 +- 在其他情况下可能的先前批准 +- 如果来自外部供应商： + - 开发团队联系人 + - 版权声明、归属、供应商修改源代码（如果需要以满足许可义务） -### Gathering Component Information +### 6.5.4 开源审查小组 -When analyzing your open source usage, you'll need to gather information about the identity of the component in question, its origin, and how the component is intended to be used. This information may include: +组建一个团队来有效地运行开源审查需要多个利益相关者的参与。 -- Package name -- Status of the community around the package (activity, diverse membership, responsiveness) -- Version -- Download or source code URL -- Copyright owner(s) -- License and License URL -- Attribution and other notices and URLs -- Description of modifications intended to be made -- List of dependencies -- Intended use in your product -- First product release that will include the package -- Location where the source code will be maintained -- Possible previous approvals in another context -- If from an external vendor: - - Development team's point of contact - - Copyright notices, attribution, source code for vendor modifications if needed to satisfy license obligations +![Image description](review-team.png) -### Open Source Review Team +开源审查团队包括支持、指导、协调和审查开源使用的公司代表。 这些代表可能包括： -Putting together a team to effectively run open source reviews requires participation from several stakeholders. +- 识别和评估许可义务的法律 +- 源代码扫描和工具支持，以帮助识别和跟踪开源使用情况 +- 从事商业利益、商业许可、出口合规等工作的工程专家，他们可能会受到开源使用的影响 -![Open Source Review Team](review-team.png) +![Image description](analyzing-usage.png) -An Open Source Review team includes the company representatives that support, guide, coordinate and review the use of Open Source. These representatives may include: +在为问题提供指导之前，开源审查团队应评估其收集的信息。 这可能包括扫描代码以确认信息的准确性。 -- Legal to identify and evaluate license obligations -- Source code scanning and tooling support to help identify and track Open Source usage -- Engineering Specialists working with business interests, commercial licensing, export compliance, etc., who may be impacted by Open Source usage +考虑因素包括： -### Analyzing Proposed Open Source Usage +- 代码和相关信息是否完整、一致和准确？ +- 声明的许可证是否与代码文件中的内容相符？ +- 许可证是否允许与软件的其他组件一起使用？ -![Analyzing Proposed Open Source Usage](analyzing-usage.png) +### 6.5.5 源代码扫描工具 -The Open Source Review team should assess the information it has gathered before providing guidance for issues. This may include scanning the code to confirm the accuracy of the information. +我们将在后面的部分中更详细地介绍不同类型的扫描工具以及选择工具时应考虑的标准，但这里是一个总体概述。 -Considerations include: +有许多不同的自动源代码扫描工具，所有解决方案都满足特定需求——因此——没有一个能解决所有可能的挑战。 因此，大多数公司都会选择最适合其特定市场领域和产品的解决方案。 一般来说，大多数公司尝试同时使用自动化工具和人工审查来抽查扫描结果。 -- Is the code and associated information complete, consistent and accurate? -- Does the declared license match what is in the code files? -- Does the license permit use with other components of the software? +免费提供的源代码扫描工具的一个流行且很好的例子是 FOSSology，这是一个由 Linux 基金会主办的项目。 -### Source Code Scanning Tools +### 6.5.6 通过开源审查工作 -We will go into more detail in a later section on the different types of scanning tools and what criteria you should be considering for choosing a tool, but here is a general overview. +![Image description](working-through-review.png) -There are many different automated source code scanning tools, and all of the solutions address specific needs and - for that reason - none will solve all possible challenges. Because of that, most companies pick the solution most suited to their specific market area and product. In general, most companies try to use both an automated tool and manual review to spot check the results of scans. +需要注意的是，开源审查过程跨学科，包括工程、业务和法律团队。 为了获得最大效率，它应该是互动的，以确保所有这些组正确理解问题，并可以创建清晰、共享的指导。 -One popular and good example of freely available source code scanning tool is [FOSSology](https://www.fossology.org/), a project hosted by the Linux Foundation. +### 6.5.7 开源审查监督 -### Working Through the Open Source Review +![Image description](review-oversight.png) -![Working Through the Open Source Review](working-through-review.png) +开源审查过程应该有执行监督来解决分歧并批准最重要的决定。 -It's important to note that the Open Source Review process crosses disciplines, including engineering, business, and legal teams. For maximum effectiveness, It should be interactive to ensure all those groups correctly understand the issues and can create clear, shared guidance. +将审查过程视为组织中的跨学科活动至关重要，因为简单地将其描述为“工程问题”或“法律问题”不仅会降低重要性，还会对工程生产力产生不利影响 和法律风险。 -### Open Source Review Oversight +将流程视为协作伙伴关系确实需要更多的前期工作来让所有利益相关者参与进来，但随着您的组织越来越熟悉端到端合规管理流程，这会带来好处。 -![Open Source Review Oversight](review-oversight.png) +## 6.6 端到端合规管理示例 -The Open Source Review process should have executive oversight to resolve disagreements and approve the most important decisions. +### 6.6.1 简介 -It's critical that the review process be treated as a cross-disciplinary activity in the organization, because simply characterizing it as "an engineering problem," or “a legal problem” not only diminishes the importance, but can have detrimental effects to both engineering productivity and legal risk. +合规性管理是一组用于管理产品中使用的开源组件的操作。 公司可能对专有组件制定了类似的流程。 -Treating the process as a collaborative partnership does require more up-front work in getting all stakeholders on board, but pays dividends as your organization becomes more familiar with the end-to-end compliance management process. +此类行动通常包括： -### Lesson: End to End Compliance Management Examples +- 识别所提供软件中使用的所有开源组件 +- 识别和跟踪由这些组件创建的所有义务 +- 确认所有义务已经或将要履行 +- 小公司可能会使用一个简单的清单，而企业可能会使用一个详细的过程 -### Introduction +![Image description](compliance-process.png) -Compliance management is a set of actions that manages Open Source components used in products. Companies may have similar processes in place for proprietary components. +### 6.6.2 示例公司清单 -Such actions often include: +这是一个示例清单，可用作您自己组织的合规性管理流程的基础。 -- Identifying all the Open Source components used in Supplied Software -- Identifying and tracking all obligations created by those components -- Confirming that all obligations have been or will be met -- Small companies may use a simple checklist and enterprises a detailed process. +正在进行的合规任务： -![Compliance Proess](compliance-process.png) +- 在采购/开发周期的早期发现所有开源软件组件 +- 审查和批准所有使用的开源组件 +- 验证满足开源义务所需的信息 +- 审查和批准对开源项目的任何对外贡献 -### Example Company Checklist +支持要求： -Here is an example checklist that can be used as a basis for your own organization's compliance management process. +- 确保配备足够的合规人员并指定明确的责任线 +- 调整现有业务流程以支持开源合规计划 +- 为所有人提供有关组织开源政策的培训 +- 跟踪所有开源合规活动的进度 -**Ongoing Compliance Tasks:** +### 6.6.3 示例企业流程 -- Discover all Open Source software components early in the procurement/development cycle -- Review and Approve all Open Source components used -- Verify the information necessary to satisfy Open Source obligations -- Review and approve any outbound contributions to Open Source projects +下面是一个典型的开源企业合规流程的图形概述： -**Support Requirements:** +![Image description](process-overview.png) -- Ensure adequate compliance staffing and designate clear lines of responsibility -- Adapt existing Business Processes to support the Open Source compliance program -- Have training on the organization's Open Source policy available to everyone -- Track progress of all Open Source compliance activities +我们将在接下来的几页中介绍此过程的重要部分。 -### Example Enterprise Process +### 6.6.3.1 识别和跟踪开源使用 -Here is a graphical overview of a typical enterprise compliance process for open source: +![Image description](identification.png) -![Enterprise Process Overview](process-overview.png) +该过程的第一步是识别代码中的开源组件。 -We'll go through the important sections of this process in the next several pages. +以下是此阶段预期的步骤和结果： -### Identify and Track Open Source Usage +**步骤** -![Identification](identification.png) +- 来自工程的传入请求 +- 软件扫描 +- 第三方软件的尽职调查 +- 手动识别添加到存储库的新组件 -The first step in the process is identification of the open source components in your code. +**结果** -Here are the steps and outcomes expected during this phase: +- 为开源创建（或更新）合规记录 +- 要求审核以根据开源政策要求在定义为详尽或有限的范围内审查源代码 -### Steps +#### 6.6.3.2 审计源代码 -- Incoming requests from engineering -- Scans of the software -- Due diligence of 3rd-party software -- Manual recognition of new components added to the repository +![Image description](audit.png) -### Outcomes +识别后，进行代码审计，具有以下步骤和结果： -- A compliance record is created (or updated) for the Open Source -- An audit is requested to review the source code with a scope defined as exhaustive or limited according to Open Source policy requirements +**步骤** -### Auditing Source Code +- 确定审计的源代码 +- 可以通过软件工具扫描源 +- 审核或扫描中的“命中”将被审查和验证代码的正确来源 +- 根据软件开发和发布生命周期迭代执行审计或扫描 -![Audit](audit.png) +**结果** -After identification, code auditing takes place, with the following steps and outcomes: +- 审计报告确定： -### Steps + - 源代码的来源和许可 + - 需要解决的问题 -- Source code for the audit is identified -- Source may be scanned by a software tool -- "Hits" from the audit or scan are reviewed and verified as to the proper origin of the code -- Audits or scans are performed iteratively based on the software development and release lifecycles +#### 6.6.3.3 解决问题 -### Outcomes +审计完成后，需要分配时间来解决在审计过程中发现的任何问题。 步骤和结果包括： -- An audit report identifying: - - The origins and licenses of the source code - - Issues that need resolving + **步骤** -### Resolving Issues +- 向适当的工程师提供反馈，以解决审计报告中与您的开源政策冲突的问题 +- 然后合适的工程师对相关的源代码进行开源审查 -![Resolving Issues](resolving-issues.png) +**结果** -Once the audit is complete, time needs to be allocated to resolving any issues that were spotted as part of the audit process. Steps and Outcomes include: +- 报告中每个标记文件的解决方案以及任何标记的许可证冲突的解决方案 -### Steps +#### 6.6.3.4 执行审查 -- Provide feedback to the appropriate engineers to resolve issues in the audit report that conflict with your Open Source policy -- The appropriate engineers then conduct Open Source Reviews on the relevant source code +![Image description](reviews.png) -### Outcomes +此时，您需要查看已解决的问题以验证解决方案是否符合您的公司开源政策。 -- A resolution for each of the flagged files in the report and a resolution for any flagged license conflict +**步骤** -### Performing Reviews +- 在审查人员中包括适当的权限级别 +- 参考您的开源政策进行审查 -![Reviews](reviews.png) +**结果** -At this point, you'll need to review the resolved issues to verify that the resolution matches your corporate open source policy. +- 确保审计报告中的软件符合开源政策 +- 保留审计报告结果并将已解决的问题标记为为下一步做好准备（即批准） -### Steps +#### 6.6.3.5 批准 -- Include appropriate authority levels in review staff -- Conduct review with reference to your Open Source policy +![Image description](approvals.png) -### Outcomes +根据之前步骤中软件审计和审查的结果，软件可能会或可能不会被批准使用。 批准应指定批准的开源组件的版本、组件的批准使用模型以及开放源代码许可下的任何其他适用义务。 -- Ensure the software in the audit report conforms with Open Source policies -- Preserve audit report findings and mark resolved issues as ready for the next step (i.e. Approval) +此外，应在适当的权限级别（必要时可达并包括执行审查委员会）进行批准。 -### Approvals +#### 6.6.3.6 注册和批准跟踪 -![Approvals](approvals.png) +![Image description](registration.png) -Based on the results of the software audit and review in previous steps, software may or may not be approved for use. The approval should specify versions of approved Open Source components, the approved usage model for the component, and any other applicable obligations under the Open Source license. +一旦一个开源组件被批准在产品中使用，它应该被添加到该产品的软件清单中，并且批准和它的条件应该在跟踪系统中注册。 -Also, approvals should be made at appropriate authority levels (up to and including the executive review committee if necessary). +跟踪系统应明确说明，开源组件的新版本需要新的批准，或者是否提出了新的使用模型。 -### Registration & Approval Tracking +#### 6.6.3.7 通知 -![Registration](registration.png) +![Image description](notices.png) -Once an Open Source component has been approved for usage in a product, it should be added to the software inventory for that product and the approval and its conditions should be registered in a tracking system. +注册后，您需要为产品发布中使用的任何开源准备适当的通知： -The tracking system should make it clear that a new approval is needed for a new version of an Open Source component or if a new usage model is proposed. +- 通过提供完整的版权和归属通知来承认使用开源 +- 告知产品的最终用户如何获取开源代码的副本（如果适用，例如在 GPL 和 LGPL 的情况下） +- 根据需要复制产品中包含的开源代码的许可协议的全文 -### Notices +#### 6.6.3.8 预分发验证 -![Notices](notices.png) +![Image description](verifications.png) -After registration, you'll need to prepare appropriate notices for any Open Source used in a product release: + 在使用任何软件之前，您需要运行高强度的步骤，包括： -- Acknowledge the use of Open Source by providing full copyright and attribution notices -- Inform the end user of the product on how to obtain a copy of the Open Source source code (when applicable, for example in the case of GPL and LGPL) -- Reproduce the entire text of the license agreements for the Open Source code included in the product as needed + **步骤** -### Pre-distribution Verifications +- 验证用于分发的公开软件包已被识别和批准 +- 验证审查的源代码与产品中提供的单一实例匹配 +- 确认已接受所有适当的通知，以告知最终用户他们为已识别的开源请求源代码 +- 努力对其他已确定的坚毅立场 -![Verifications](verifications.png) +**结果** -Prior to any software distribution, you'll need to run a series of verifications steps including: +- 分发包仅经过审核和批准的软件 +- “传播合规性对象”（在 OpenChain 规范中定义），包括适当的通知文件，包含在分发包或其他交付中 -### Steps +#### 6.6.3.9 随附的源代码分发 -- Verify Open Source packages destined for distribution have been identified and approved -- Verify the reviewed source code matches the binary equivalents shipping in the product -- Verify all appropriate notices have been included to inform end-users of their right to request source code for identified Open Source -- Verify compliance with other identified obligations +![Image description](distributions.png) -### Outcomes +在流程的这个阶段，您已准备好提供随附的源代码，以满足所用开源代码的许可规定的任何许可义务。 您需要确保： -- The distribution package contains only software that has been reviewed and approved -- "Distributed Compliance Artifacts" (as defined in the OpenChain specification), including appropriate notice files are included in the distribution package or other delivery method +- 提供随附的源代码以及任何相关的构建工具和文档（例如，通过上传到分发网站或包含在分发包中） +- 用标签标识随附的源代码对应的产品和版本 -### Accompanying Source Code Distributions +#### 6.6.3.10 最终验证 -![Distributions](distributions.png) +![Image description](distributions.png) -At this stage of the process, you're ready to provide the accompanying source code to meet any license obligations specified by the license of the open source code used. You'll need to make sure to: +在这最后的验证步骤中，您需要通过以下方式验证您是否遵守了所有适当的许可义务： -- Provide accompanying source code along with any associated build tools and documentation (e.g., by uploading to a distribution website or including in the distribution package) -- Identify accompanying source code with labels for which product and version it corresponds to +- 验证随附的源代码（如果有）已正确上传或分发 +- 验证上传或分发的源代码与批准的相同版本 +- 验证通知已正确发布并提供 +- 验证其他已确定的义务得到满足 -### Final Verifications +# 7. 选择正确的许可证合规工具 -![Final Verifications](final-verifications.png) +## 7.1 简介 -In this final verification step, you'll need to validate that you've complied with all appropriate license obligations by: +在本节中，我们将更详细地研究许可证合规性工具，包括提供有关工具将解决哪些类型的问题以及在为您的组织确定最佳合规性工具和扫描软件时应考虑哪些类型的标准的上下文。 -- Verifying accompanying source code (if any) has been uploaded or distributed correctly -- Verifying uploaded or distributed source code corresponds to the same version that was approved -- Verifying notices have been properly published and made available -- Verifying other identified obligations are met +## 7.2 学习目标 -# Section: Choosing the Right License Compliance Tool +在本节结束时，您应该能够： -## Lesson: Introduction +- 描述整体合规性工具格局和适当的工具用例 +- 解释可用的不同类型的合规工具 +- 知道去哪里获取有关不同类型合规工具的更深入信息 -### Section Overview +## 7.3 工具用例 -In this section, we will look in more detail at license compliance tooling, including providing context around what kinds of problems tooling will solve and what kinds of criteria you should be considering as you determine the best compliance tooling and scanning software for your organization. +### 7.3.1 简介 -### Learning Objectives +毫无疑问，您已经从本模块的内容中确定了这一点，从概念上讲，合规性相当简单。 挑战来自可用于开源世界的软件数量，以及它可以与您自己组织的软件结合的各种方式。 -By the end of this section, you should be able to: +因此，跟踪和建立有效的合规流程需要各种形式的工具，以帮助减少可能的人为错误并加快实现合规的过程。 但是，在考虑可能的工具时，有一些重要的事情需要考虑： -- Describe the overall compliance tool landscape and appropriate tool use cases -- Explain the different kinds of compliance tools that are available -- Know where to go for more in-depth information on different kinds of compliance tools +- 先了解需求和流程，再确定工具 +- 工具不能提供（困难的）决策，而只能提供这些决策的数据 +- 很多情况下都需要专业知识，即使是使用工具 -## Lesson: Tooling Use Cases +### 7.3.2 关于工具 -### Introduction +![Image description](tools.png) -As you've undoubtedly determined from the content in this module to this point, conceptually, compliance is fairly straightforward. The challenge comes in the form of the amount of software that's available to use in the open source world and the variety of ways in which it can be combined with your own organization's software. +如您所见，工具可用于许多不同的合规领域。 然而，抵制将所有这些工具构建为整体堆栈的冲动。 确定您最大的潜在痛点是什么让您有机会以开源/敏捷风格（例如，随着合规性需求的增长以迭代方式）构建工具。 -Tracking and building an effective compliance process therefore requires tooling in various forms to help alleviate possible human error and speed up the process of achieving compliance. However, there are some important things to consider as you think about possible tooling: +### 7.3.3 软件情况 -- First understand the demand and process, then determine the tool -- A tool cannot provide (difficult) decisions, but only data for those decisions -- There will be many cases where expert knowledge is required, even with tooling +![Image description](software-situation.png) -### About Tools +当您考虑工具时，重要的是要考虑您将要解决的不同类别的软件和情况。 如上所述，您基本上需要考虑三类：入站、您自己的和出站软件。 - +### 7.3.4 来自 10k 英尺的合规工具箱 -![Tools](tools.png) +![Image description](compliance-tooling.png) -As you can see, there are many different areas of compliance where tooling can be put to use. However, resist the urge to build all of this tooling as a monolithic stack. Determining what your biggest potential pain points are gives you the opportunity to build out tools in an open source/agile style (e.g. - in an iterative fashion as your compliance needs grow). +在高层次上，您需要考虑上面提到的情况以及在考虑工具需求时需要什么。 -### Software Situation +对于入站软件，记录实际情况（许可类型、义务等）至关重要。 对于您自己的软件，您需要在了解链接或调用开源包的方式和原因方面进行质量控制。 对于组合的 Outbound 软件，您需要了解您的可交付成果在您的软件和开源组件的组合包中的样子，并确保您遵守与分发相关的所有许可义务。 -![Software Situation](software-situation.png) +在分析入站软件时，有几个方面需要考虑，其中最重要的是，即使入站商业软件本身也可以包含开源（其分发的一部分）。 考虑以下事项也很重要： -As you think about tooling, it's important to consider the different categories of software and situations you'll be addressing. As noted above, you basically have three categories: Inbound, Your Own, and Outbound software to consider. +- 确定涉及哪些开源组件 +- 识别与开源组件相关的许可证 +- 确定作者身份和版权 +- 确定许可义务 +- 导入、依赖项、使用的库等的声明。 +- 软件中包含的任何二进制文件的来源和内容 -### Compliance Tooling Cases from 10k Feet +### 7.3.5 入站软件 -![Compliance Tooling](compliance-tooling.png) +#### 7.3.5.1 识别入站许可证 -At a high level, you need to consider the cases noted above and what's required as you think about your tooling needs. +确定入站软件的许可证可能相对容易，或者可能非常具有挑战性。 这是工具可以提供很大帮助的原因之一。 以下是有关简单案例和更具挑战性的案例的一些详细信息。 -For Inbound software, it's critical that you document the actual situation (license type, obligations, etc.). For your own software, you need to exercise quality control in terms of understanding how and why you are linking to or calling open source packages. For the combined Outbound software, you need to understand what your deliverable looks like in the combined package of your software and the open source component and make sure you are abiding by all license obligations related to distribution. +#### 7.3.5.2 简单案例 -### Analyzing Inbound Software +- 随软件提供的许可、复制或通知文件 +- 在基础设施、主页或项目页面内 + - 例如 Github 或其他存储库元数据 +- 项目定义文件 + 例如 在 Java pom.xml 中 + 已提供许可证信息 + 例如 debian-copyright 或机器可读的文档 -![Analyzing Inbound Software](analyzing-inbound.png) +#### 7.3.5.3 具有挑战性的案例 -There are several areas to consider as you analyze inbound software, not the least of which is that even inbound commercial software can itself contain open source (part of their distribution). It's also important to think about: +- 许可证激增，现有 350 多个“主要”许可证（还有更多） +- 不同语言的许可证（例如法语 CeCILL） +- EULA（最终用户许可协议）等商业许可缺乏标准化 +- 由于大量重用，开源组件并不（总是）同质化 +- 代码可以来自具有不同许可的许多来源 +- 项目可能不会对所有贡献强制执行通用许可 +- 由于没有标准格式，识别许可证声明可能具有挑战性 -- Identifying which open source components are involved -- Identifying licenses associated with open source components -- Identifying authorships and copyrights -- Determining licensing obligations -- Declaration of imports, dependencies, used libraries, etc. -- Origin and contents of any binaries included with the software +#### 7.3.5.4 识别版权 -### Identifying Inbound Licenses +一些许可证要求提供版权声明或作者列表，导致有义务提供这些，但正如您在下面看到的，有时解析和解开版权声明可能会出现问题，因此这通常是软件（以及像 SPDX 这样的项目，我们 稍后会详细介绍）进来。 -Figuring out the licenses for inbound software can be relatively easy, or potentially very challenging. It's one of the reasons that tools can help a great deal. Here are some details on the easy cases and the more challenging ones. +![Image description](copyright.png) -### Easy Cases +#### 7.3.5.5 使用二进制文件识别许可证 -- License, copying or notice document provided along with software -- Within infrastructure, home page or project pages - - e.g. Github or other repository metadata -- Project definition file - - e.g. in Java pom.xml -- Already provided license info - - e.g debian-copyright or machine-readable documentation +二进制文件是已编译的应用程序、库、软件，无需访问源代码即可使用。 二进制文件可以是开源组件分发的一部分，并且本身可以包含开源。 -### Challenging Cases +这里的主要问题围绕如何理解二进制文件中包含的内容： -- License proliferation with over 350 "main" licenses in existence (with more cropping up) -- Licenses in different languages (e.g. the French CeCILL) -- Commercial licenses such as an EULA (End User License Agreement) lack standardization -- Open source components are not (always) homogeneous because of extensive reuse -- Code can come from many sources with different licensing -- Projects may not enforce common licensing for all contributions -- Identifying license statements can be challenging because of no standard format +- 主要问题1：不同的二进制技术和硬件架构 +- 主要问题2：源代码的微小变化可以生成全新的二进制文件 -### Identifying Copyright +### 7.3.6 您自己的软件 -Some licenses ask for copyright notice or author listing, resulting in an obligation to provide these, but as you can see below, sometimes parsing and untangling copyright notices can be problematic, so this is usually where software (and projects like SPDX, which we'll cover a bit more later) come in. +![Image description](own-software.png) -![Identifying Copyright](copyright.png) +虽然希望您的组织能够养成良好的编码和工程习惯，但总是有“复制和粘贴”解决方案进入您的代码库的诱惑。 造成这种情况的原因有很多，包括： -### Identifying Licenses with Binaries +- 开源项目是公开可用的 +- 但其他文件也很有价值：脚本、图标、图像、css 文件 +- 从网站复制的小段代码以获得最佳实践和片段更容易 -Binaries are compiled applications, libraries, software that can be used without access to source code. Binaries can be part of an open source component distribution and can themselves contain open source. +可以将 Internet 上的源代码复制并粘贴到您的代码中，因为重用通常比每次都重新发明轮子要好。 但是，通过遵守任何许可或版权义务来尊重作者的利益很重要. -The main issues here revolve around how to understand what is contained in a binary: +### 7.3.7 出站软件 -- Main problem 1: different binary technologies and hardware architectures -- Main problem 2: small variations in source can generate a completely new binary +![Image description](outbound.png) -### Your Own Software +当您开始打包产品以进行销售或分发时，您需要关注组合的出站软件堆栈在开源合规性以及其他辅助任务的背景下是什么样子。 我们将在接下来的页面中介绍这些项目。 -![Your Own Software](own-software.png) +#### 7.3.7.1 开源代码的分发 -While it is hoped that your organization will practice good coding and engineering habits, there is always a temptation for "copy & paste" solutions to make their way into your code base. There are many reasons for this including: +如果您的项目或产品将分发开源作为您交付的一部分，您需要: -- Open source projects are publicly available -- But also other files are valuable: scripts, icons, images, css files -- Small sections of code copied from Web sites for best practices and snippets is easier +- 通知文件，由 + -所有许可的清单 + -所有版权通知的清单 +- 提供开放源代码的书面提议 -Copying and paste of source code from the Internet in your code can be done, as reuse is generally better than reinventing the wheel each time. However, it's important to respect the author's interests by observing any licensing or copyright obligations. +为了能够提供所有这些，您将需要收集以下信息的工具: -### Outbound Software +- 您的软件中有哪些开源组件 +- 哪些许可和版权声明附加在这些组件上 -![Outbound Software](outbound.png) +#### 7.3.7.2 保障发行权 -When you begin to package your product for sale or distribution, you'll need to focus on what the combined outbound software stack looks like in the context of open source compliance, as well as other ancillary tasks. We'll cover these items in the following pages. +由于您的合规性目标是确保您对所使用的开源代码履行所有适当的义务，因此您需要考虑对出站软件中的许可证进行工具和人工审查。 -### Distribution of Open Source +例如，某些许可证不兼容，例如 GNU 公共许可证 (GPL) 和 Eclipse 公共许可证 (EPL)，基于包含 GPL 和 EPL 许可证的代码的作品可能会出现问题。 -If your project or product will be distributing open source as part of your deliverable, you'll need: +此外，即使使用工具，一些许可声明也是模棱两可的，例如“在 BSD 下许可”。在这种情况下，让您的法律团队和利益相关者参与决定如何进行是很重要的。 -- A notice file, consisting of - - A listing of all licenses - - A listing of all copyright notice -- A written offer to provide the open source code +#### 7.3.7.3 物料清单 (BOM) -To be able to provide all of this, you'll need tooling which gathers the following information: +代码扫描或合规性工具可以提供的最关键的事情之一是一种确定您要交付的软件或产品中的内容的编程方式。这是材料清单 (BOM) 的形式。 -- Which open source components are in your software -- Which licenses and copyright notices are attached to those components +BOM 提供了软件包交付内容的详细说明，包括确定该软件包中有多少由开源组件组成，以及这些组件使用了哪些许可证。 -### Ensuring Distribution Rights +软件包数据交换 (SPDX) 项目指定了如何表达物料清单的一种实现。 -Since your goal with compliance is to ensure that you are meeting all appropriate obligations for the open source code you use, you'll need to consider both tooling **and** human review of licenses in your outbound software. +#### 7.3.7.4 工具支持摘要 -For example, some licenses are not compatible, such as the GNU Public License (GPL) and the Eclipse Public License (EPL), and works based on code containing GPL and EPL licenses can be problematic. +我们将在下一节中介绍不同类型的工具，但重要的是要了解哪些工具可以提供合规性，以及在选择解决方案之前需要考虑哪些方面。 -In addition, even with tooling, some license statements are ambiguous, for example "Licensed under BSD". In cases like this, it's important to involve your legal team and stakeholders in determining how to proceed. +从本节中可以看出，建立有效的合规性需要一些东西，工具绝不是可以消除所有合规性负担的“灵丹妙药”。工具非常擅长分析、报告和帮助推动管理决策，但它们不能孤立运行——它们需要一个有效的流程，结合一套明确的期望和政策来使用开源，以及分发你自己构建的软件基于开源包。 -### Software Bill of Materials (SBOM) +请记住，也不一定有满足所有需求的单一工具，因此您可能会处理不同系统/工具的集成，并且您应该清楚地了解工具提供的 API 和接口，以减少手动操作整合努力。 -One of the most critical things that code scanning or compliance tooling can provide is a programmatic way of determining what is in the software or product that you are shipping. This is in the form of a Software Bill of Materials (SBOM). +# 8. 工具类型 -An SBOM provides a detailed account of what is in a software package delivery, including identifying how much of that software package consists of open source components and which licenses are in use for those components. +## 8.1 概览 -The [Software Package Data Exchange (SPDX)](https://spdx.org) project specifies one implementation of how to express a Software Bill of Materials. +开源合规领域有许多类型的工具，包括（但不限于）： -### Tool Support Summary +- 源代码扫描 +- 许可证扫描 +- 二进制扫描 +- 开发运营集成 +- 组件管理 -We will cover different types of tooling in our next section, but it's important to understand what tools can provide in compliance, and also what areas need to be considered before choosing a solution. +我们将在接下来的页面中介绍这些领域中的每一个。 -As you can see from this section, there are several things that are needed in building effective compliance, and tooling is by no means a "silver bullet" that will make all compliance burdens go away. Tools are very good at analysis, reporting and helping drive management decisions, but they cannot operate in isolation - they need an effective process, married to a clear set of expectations and policies for consuming open source, as well as distributing your own software which builds upon open source packages. +## 8.2 源代码扫描 -Remember that there also isn't necessarily a single tool that meets all needs, so you will likely be dealing with integration of different systems/tools, and you should have a clear understanding of what APIs and interfaces the tools provide in order to reduce manual integration effort. +![Image description](source-scanning.png) -## Lesson: Tooling Types +由于组织可以访问自己的源代码以及用于构建其产品的开源包，因此源代码扫描工具是合规领域使用最广泛的工具之一。 -### Overview +有许多商业工具（和一些开源工具）可以执行此功能。通常，这些工具依赖于现有开源代码库（或者，如果添加到扫描数据库的潜在内部组件）的“散列”指纹来确定哪些软件组件是分发的一部分。他们最大的优势之一是构建我们之前提到的物料清单 (BOM)。 -There are many types of tools in the open source compliance space, including (but not limited to): +一些扫描工具还可以识别“代码片段”，这在确定是否使用了来自特定开源包的“复制和粘贴”代码时通常很有帮助。然而，片段扫描是有代价的——对源代码运行完整的片段扫描分析通常需要更长的时间，而不仅仅是依赖散列指纹。 -- Source code scanning -- License scanning -- Binary scanning -- DevOps integration -- Component management +许多这些工具的最大区别在于它们的数据源——它们的数据库多久更新一次，以及它们的数据中有多少开源代码。构建环境的成本、复杂性、集成能力和报告功能也是您在选择工具之前需要评估的关键功能。 -We'll cover each of these areas in the following pages. +还有可能出现“误报”或需要引入专家知识（法律、工程）来确定源代码扫描结果的相关性的情况。 -### Source Code Scanning +## 8.3 许可证扫描 -![Source Code Scanning](source-scanning.png) +![Image description](license-scanning.png) -Since organizations have access to their own source code, as well as the open source packages used to build their products, source code scanning tools are some of the most widely used tools in compliance. +虽然我们将许可证扫描工具作为一个单独的项目进行介绍，但实际上，大多数商业源代码扫描工具也包括许可证扫描功能。 -There are many commercial tools (and some open source ones) available that perform this function. In general, these tools rely on "hashing" fingerprints of existing open source code bases (or, potentially internal components if added to the scanning database) to make a determination of what software components are part of a distribution. One of their biggest advantages is in building the Software Bill of Materials (SBOM) we mentioned earlier. +许可证扫描依赖于搜索相关关键字和/或机器可读标记（例如 SPDX 块）的源代码来确定附加到每个文件或包的相关许可证。这些扫描还可以识别版权、作者声明和有时的致谢。 -Some scanning tools can also identify "code snippets", which is often helpful when determining if "copy and pasted" code from a particular open source package was used. However, snippet scanning comes at a price - it will often take longer to run a full snippet scan analysis on source code rather than just relying on hashed fingerprints. +虽然开源许可证数据库不如在 BOM 中构建组件标识部分所需的开源组件数据库大，但它仍然需要访问现有开源许可证的知识库。一般来说，许可证扫描很难识别非 OSS 许可证，因为这些类型的许可证种类繁多。 -The biggest differentiator for many of these tools is their data sources - how often their databases are updated, and how much open source code is represented in their data. Cost, complexity, integration ability for your build environment, and reporting features are also key features you'll need to evaluate before making a tool selection. +如前所述，许可证扫描的主要用途是检查入站开源软件以验证正在使用的许可证。这通常是在验证用于您的组织的开源组件之前执行的第一步（在评估技术目的的适用性之后）。 -There is also the possibility of "false positives" or cases where expert knowledge may need to be brought in (legal, engineering) to determine the relevance of results from source code scanning. +即使采用最佳模式匹配或机器可读标记的使用，也可能存在需要利用法律或工程利益相关者来澄清可能不明确的许可证标识的情况。 -### License Scanning +## 8.4 二进制扫描 -![License Scanning](license-scanning.png) +二进制扫描的目的类似于源代码扫描（识别开源组件及其版本），可以帮助创建 BOM，以及识别进入组织的特定软件包的潜在漏洞。 -While we are covering license scanning tools as a separate item, in practice, most commercial source code scanning tools also include license scanning capabilities. +当然，这里的挑战是，如果没有可读的源代码，二进制扫描是一种启发式方法，它依赖于二进制文件的一些特征元素，例如字符串变量、文件名，有时还有来自具有运行时代码的语言的方法和字段名称（例如 爪哇）。 由于硬件架构和编译器会随着时间的推移而变化，因此必须经常调整二进制扫描器以尝试并考虑这些变化。 -License scanning relies on searching source code for relevant keywords, and/or machine readable markers (such as SPDX blocks) to determine the relevant licenses attached to each file or package. These scans can also identify copyright, author statements and sometimes acknowledgements. +在某些情况下，特定二进制文件无法完全获得可靠的扫描。 但是，如果可以尝试在没有源代码的包中识别开源，扫描二进制文件仍然是一个好主意。 -While the database of open source licenses isn't as large as the database of open source components required to build a component identification piece in the SBOM, it still does require access to a knowledge base of existing open source licenses. In general, license scanning has a harder time identifying non-OSS licenses, as there are a larger variety of these types of licenses. +## 8.5 DevOps集成 -As noted earlier, a primary use of license scanning is when checking inbound open source software to verify the license in use. This is often one of the first steps performed (after evaluation for fitness of technical purpose) before validating an open source component for use in your organization. +![Image description](devops.png) -Even with the best pattern matching or utilization of machine-readable markers, there may be cases where legal or engineering stakeholders need to be utilized to clarify a license identification that may be ambiguous. +使用定制软件和定制流程的 DevOps 集成可用于增强前面提到的其他扫描机制，并从用于构建软件的流程中获取更多信息。 -### Binary Scanning +由于 DevOps 构建系统能够在构建期间确定依赖关系，因此它可以将该信息与其他工具的输出相结合，以帮助创建更强大的 BOM。 对于可能具有复杂依赖关系或软件中可能无法被商业或开源扫描技术正确识别的遗留包的开发组织来说尤其如此。 -![Binary Scanning](binary-scanning.png) +一个缺点是这些自定义配置/系统确实需要努力构建和维护，但如果您的组织已经有一个与 DevOps 基础设施相关联的构建系统，则可能将外部扫描工具集成到此环境中，并可能有助于减轻相当多的负担 人工审查/合规工作。 -The purpose of binary scanning is similar to source code scanning (identification of open source components and their versions), which can help with SBOM creation, as well as identification of potential vulnerabilities for specific software packages coming into your organization. +## 8.6 组件管理 -The challenge here, of course, is that without readable source code, binary scanning is a heuristic that relies on some characteristic elements of binaries, such as string variables, filenames and sometimes method and field names from languages with run-time code available (e.g. Java). Because hardware architectures and compilers can change over time, binary scanners have to be frequently adjusted to try and account for these changes. +![Image description](components.png) -There are also some cases where a reliable scan isn't fully available for a particular binary. But, it's still a good idea to scan binaries if you can in an attempt to identify open source in packages that you don't have the source code for. +组件管理系统是一个方便的合规工具，可帮助您整合各种相关的物料清单 (BOM) 并提供文档和报告。 有各种商业供应商和一些开源项目（搜索 github.com）提供这种功能。 -### DevOps Integration +一些组织甚至选择为自己编写这种数据库程序，但重要的是它可以在很多方面提供帮助，包括漏洞管理、开源组件的审批、许可证的跟踪以及识别哪些开源组件 用于组织中的所有软件。 -![DevOps Integration](devops.png) +将此作为 Web 门户实施可以帮助多个利益相关者，尤其是法律、安全甚至工程团队，当他们必须解决许可证合规性、安全漏洞或跟踪组织中使用的开源组件版本等问题时。 -DevOps integration using custom-built software and custom processes can be used to augment other previously mentioned scanning mechanisms and gain additional information from the processes used to build the software. +## 8.7 法规遵循工具的行业计划 -Because the DevOps build system is able to determine dependencies during builds, it can combine that information with the output of other tools to help create a more robust SBOM. This is especially true of development organizations that may have intricate dependencies, or legacy packages in their software that are unlikely to be identified correctly by commercial or open source scanning technologies. +### 8.7.1 概览 -The one downside is that these custom configurations/systems do require effort to build and maintain, but if your organization already has a build system tied to a DevOps infrastructure, integrating outside scanning tools into this environment may be possible and may help alleviate a fair amount of manual review/compliance work. +围绕合规性工具出现了许多行业计划，包括用于扫描的 FOSSology、Microsoft 的 ClearlyDefined 和 tl;dr Legal 用于许可澄清和审查，以及许多其他计划。 -### Component Management +在接下来的两页中，我们将重点介绍两个对自动化和供应链工作很重要的举措，以帮助使开源在组织中更具可持续性和更容易使用——SPDX 和 OpenChain。 -![Component Management](components.png) +### 8.7.2 SPDX -A handy compliance tool to help you bring together your various associated Software Bill of Materials (SBOMs) and provide documentation and reporting is a Component Management System. There are various commercial vendors and some open source projects (search [github.com](https://github.com/)) that provide this kind of functionality. +软件包数据交换 (SPDX) 是一个项目、一个标准和一组许可数据，有助于将机器（和人类）可读的许可信息嵌入到源代码中，而且还可以在不同的合规工具和系统之间进行交换。 -Some organizations even choose to write this kind of database program for themselves, but the important thing is that it can help with a variety of things, including vulnerability management, approval of open source components, tracking of licenses, and identification of which open source components are used throughout all of the software in an organization. +SPDX 还是一个精英社区工作组，开发了一套抵押品，可用于以标准/可重复使用的方式更清晰地传达完整的许可证信息并促进合规性。这样做的优点是： -Implementing this as a web portal can help multiple stakeholders, especially legal, security, and even engineering teams when they have to address questions of license compliance, security vulnerabilities, or tracking versions of open source components in use in the organization. +- 建立通用数据格式（SPDX 文档）可以减少在许可证合规性方面的多余工作。只有在特定代码库中识别出所有软件和相关许可证后，许可证合规性才能开始。 +- SPDX 文档的内容通常包括明确标识软件包、包级别以及文件级别许可和版权信息的信息。它还提供有关分析本身的元数据：谁创建了文件、何时创建以及如何创建。 +- 标准格式允许创建工具以提高流程效率并允许进行更复杂的合规操作。 -## Lesson: Industry Initiatives for Compliance Tooling +到目前为止，在我们的工具讨论上下文中，最后一点可能是最重要的——对于商业、开源或定制的合规性工具，拥有标准格式来交换许可证数据的能力绝对是至关重要的——没有这一点，将有大量的手动工作和审查来保持有效的开源合规性。 -### Overview +### 8.7.3 OpenChain -There are a host of industry initiatives that have sprung up around compliance tooling, including [FOSSology](https://www.fossology.org/) for scanning, Microsoft's [ClearlyDefined](https://clearlydefined.io/) and [tl;dr Legal](https://tldrlegal.com/) for license clarification and review, and many others. +OpenChain 项目是质量开源合规计划关键要求的行业标准。 该项目提供了一个规范和认证计划，涉及源代码、构建脚本、许可证副本、归属通知、修改通知、SPDX 数据和其他管理软件可交付成果的开源许可证可能需要的材料的供应链交换。 -In the next two pages, we'll highlight two initiatives that are important for automation and supply chain efforts to help make open source more sustainable and easily consumed in organizations - SPDX and OpenChain. +此外，该项目提供了一套课程，以及一个免费的评估工具，可以帮助您的组织确定可以改进哪些领域以帮助您自己的开源合规性。 -### SPDX +也许最重要的是，OpenChain 是一个不断壮大的社区，他们是刚刚开始开源合规之旅的组织的重要资源。 -[Software Package Data Exchange (SPDX)](https://spdx.org) is a project, a standard, and a set of license data that helps enable machine (and human) readable license information to be embedded in source code, but also exchanged between different compliance tools and systems. +# 9. 开源审计在并购活动中的作用 -SPDX is also a meritocratic community workgroup developing a set of collateral that can be used to more clearly convey complete license information in a standard/reusable fashion and to facilitate compliance. The advantages of this are: +## 9.1 课程简介 -- Establishing a common data format (SPDX Documents) allows less redundant effort to be expended on license compliance. License compliance can only begin once all software and associated licenses have been identified in a particular code base. -- The content of an SPDX document typically comprises information definitively identifying the software package, package level, and file level licensing and copyright information. It also provides metadata about the analysis itself: who created the file, when, and how. -- Standard formats allow for tooling to be created to make the process more efficient and to allow more complex compliance operations to take place. +在本节中，我们将解释开源审计在兼并与收购 (M&A) 活动为您的现有产品带来新代码时所起的作用。 有效的审计可以帮助遵守法律，同时也是识别软件重用领域的战略手段。 -The last point here is probably the most important in the context of our tooling discussion so far - for commercial, open source, or custom-built compliance tools, the ability to have a standard format to exchange license data is absolutely critical - without that, there would be a lot of manual effort and review to maintain effective open source compliance. +## 9.2 学习目标 -### OpenChain +在本节结束时，您应该能够： -The [OpenChain Project](https://www.openchainproject.org/) ISO 5230 is the International Standard for the key requirements of a quality open source compliance program. The project provides a specification and certification program regarding supply chain exchanges of source code, build scripts, license copies, attribution notices, modifications notices, SPDX data and other materials open source licenses governing a software deliverable may require. +- 描述最常用的开源合规审计方法 +- 解释作为收购目标或收购公司如何准备审计 -Additionally, the project provides a set of curriculum, as well as a free [assessment tool](https://www.openchainproject.org/get-started/conformance) that can help your organization determine what areas can be improved to help your own open source compliance. +## 9.3 概览 -Perhaps most important of all, OpenChain is a growing [community](https://www.openchainproject.org/webinars-interviews) of people who are a great resource for organizations just starting on their journey in open source compliance. +### 9.3.1 介绍 -# Section: The Role of Open Source Audits During M&A Activities +我们已经确定该软件，特别是开源软件，不仅在技术公司中发挥着重要作用，而且在许多以前不涉足软件或技术业务的公司中也发挥着重要作用。到目前为止，在本模块中，我们已经详细介绍了为入站软件、您自己的软件和出站软件构建有效的合规流程意味着什么。 -## Lesson: Introduction +当一个组织即将获得另一家公司的知识产权（软件方面）时，会出现 Inbound Software 的一个特殊情况。这种软件尽职调查过程，在该过程中，收购方对目标的软件及其合规实践进行全面审查，正成为任何合并或收购的标准部分。在此过程中，经常会遇到开源软件，这会带来一系列不同于专有软件的验证挑战。 -### Section Overview +在本节的其余部分，我们将概述并购 (M&A) 交易中的开源审计流程。 -In this section, we will provide an explanation of the role that open source audits play when Mergers & Acquisitions (M&A) activities bring in new code to your existing products. Effective audits can help with both legal compliance as well as be a strategic means to identify areas for software reuse. +### 9.3.2 为什么要进行审计？ -### Learning Objectives +虽然每笔并购交易都不同，但验证获得开源义务的影响的需求是不变的。进行开源审计是为了了解使用深度和对开源软件的依赖。此外，他们还提供了有关任何合规性问题甚至目标工程实践的深刻见解。 -By the end of this section, you should be able to: +开源软件可以影响所收购资产的方式示例包括： -- Describe the most commonly used audit methods for open source compliance -- Explain how to prepare for an audit as either the acquiring target, or the acquiring company +- 根据 GNU 通用公共许可证 (GNU GPL) 许可的任何软件也需要在同一许可证下提供衍生产品或组合，这可能会影响使用开源代码的任何专有代码。 +- 其他许可证需要文档中的某些通知或对产品的推广方式有限制。 +- 未能满足开源许可义务可能会导致可能的诉讼、昂贵的重新设计、产品召回和不良宣传。 -## Lesson: Overview +一个常见的问题是是否需要进行开源审计。答案因公司、收购目的和源代码库规模而异。例如，对于小型收购，一些公司更愿意只查看收购目标提供的开源物料清单 (BOM)（假设它可用），并与他们的工程负责人讨论他们的开源实践。即使收购的目的是获得人才，审计也可以帮助发现是否存在由于已经发货的产品的历史许可义务而导致的未披露负债。 -### Introduction +### 9.3.3 输入和输出 -We've already established that software, and specifically open source software, plays a big role in not only technology companies, but many companies that previously weren't in the software or technology business. So far in this module, we've covered the details of what it means to build an effective compliance process for Inbound Software, Your Own Software, and Outbound Software. +![Image description](audit-inputs-outputs.png) -A special case for Inbound Software occurs when an organization is about to acquire the intellectual property (in software) of another company. This software due diligence process, in which the acquirer performs a comprehensive review of the target's software and their compliance practices, is becoming a standard part of any merger or acquisition. During this process it's common to encounter open source software, which presents a set of verification challenges different from proprietary software. +审计过程有一个主要输入和一个主要输出（见上图）。 该流程的输入是正在进行的并购交易的完整软件堆栈主题。 这包括专有、开源和 3rd 方软件。 -In the rest of this section, we'll provide an overview of the open source audit process in merger and acquisition (M&A) transactions. +在流程的最后，主要输出是一份详细的开源软件材料清单，其中列出了： -**Why Conduct an Audit?** +- 所有用作组件的开源软件、它们的来源和确认的许可证 +- 专有或第三方软件中使用的所有开源代码片段、它们的原始组件和确认的许可证 -While every M&A transaction is different, the need to verify the impact of acquiring open source obligations is a constant. Open source audits are carried out to understand the depth of use and the reliance on open source software. Additionally, they offer great insights about any compliance issues and even about the target's engineering practices. +### 9.3.3 评估审计范围 -Examples of ways open source software can impact the acquired assets include: +审计的规模、范围和成本因事务而异，并且通常随着源代码的大小和复杂性而增加。为了确定开源审计的成本和时间，审计人员需要对代码库的大小和特征，以及项目的紧迫性有一些基本的了解。 -- Any software licensed under the GNU General Public License (GNU GPL), requires derivatives or combinations to be made available under the same license as well, which could affect any proprietary code that is using the open source code. -- Other licenses require certain notices in documentation or have restrictions for how the product is promoted. -- Failure to satisfy open source license obligations can lead to possible litigation, expensive re-engineering, product recalls, and bad publicity. +第一个问题将与代码度量相关，例如源代码库的大小、源代码的行数以及需要审核的文件数。审计员还会询问代码库是否仅由源代码组成，或者它是否包含二进制文件、配置文件、文档和其他可能的文件格式。有时，审计人员了解受审计的文件扩展名也很有帮助。正如我们在本模块中已经学到的，了解这些内容将有助于团队选择正确的工具来支持审计。 -A common question is whether an open source audit is needed at all. The answer differs by company, purpose of acquisition, and size of the source code base. For instance, for small acquisitions, some companies prefer to just review the open source bill of materials (BOM) -provided by the acquiring target (assuming it is available) and have a discussion with their engineering lead about their open source practices. Even if the purpose of the acquisition is to acquire the talent, an audit can help uncover whether there are undisclosed liabilities due to historical license obligations from products which have already shipped. +由于审计价格讨论在流程的早期根据规模和范围进行，因此收购方可能无法访问上述所有信息。审计员至少需要在继续之前了解要扫描的文件数量，尽管附加信息将有助于改进估计。当审计师有足够的信息来了解工作范围时，他们还需要了解紧迫性，因为这对审计成本有重大影响。 -**Inputs & Outputs** +## 9.4 审计方法 -![Inputs & Outputs](audit-inputs-outputs.png) +### 9.4.1 概览 -The audit process has one primary input and one primary output (see figure above). The input to the process is the complete software stack subject of the M&A transaction being conducted. This includes proprietary, open source and 3rd party software. +根据审计员在初始采购讨论阶段发现的情况，他们可能不得不依赖多种类型的工具（扫描、许可证识别、组件管理）来执行审计。 -On the end side of the process, the primary output is a detailed open source software bill of materials that lists: +有两种审计方法： -- All open source software used as components, their origin and confirmed licenses -- All open source snippets used in either proprietary or third-party software, their originating components, and confirmed licenses -- All 3rd party software components and snippet without any license -- (All 3rd party commercial software components and snippets) +- 传统审计，其中审计员可以完全访问所有代码并远程或现场执行审计。 +- “自己动手”审计，目标公司或收购方使用工具自行执行大部分实际审计工作，并可选择对审计公司的结果进行随机验证。 -**Assessing the Scope of an Audit** +### 9.4.2 传统审计 -The size, scope, and cost of an audit varies by transaction, and generally increases with source code size and complexity. To determine the cost and time for an open source audit, auditors need to get some basic understanding of the size and characteristics of the code base, as well as the urgency of the project. +![Image description](traditional-audit.png) -The first questions will be related to code metrics, such as the size of the source code base, the number of lines of source code, and the number of files that need to be audited. Auditors also ask if the codebase consists exclusively of source code, or if it includes binary files, configuration files, documentation, and possibly other file formats. Sometimes, it is also helpful for the auditor to know the file extensions subject to the audit. As we've already learned in this module, understanding these things will help the team pick the right tools to support the audit. +这种方法被称为传统方法，因为它是用于开源合规性目的的源代码扫描的原始方法。传统审计是第三方审计公司的合规审计员通过云系统远程访问源代码或在访问现场时物理访问源代码并执行源代码扫描的审计。 -Because audit price discussions happen early in the process based on size and scope, the acquirer may not have access to all the information described above. At minimum, the auditor needs to understand the number of files to be scanned before proceeding, although additional information will help refine the estimates. When the auditor has enough information to understand the scope of the work, they will also need to understand the urgency, as this has a significant impact on the cost of an audit. +请注意，不同服务提供商的流程可能略有不同。典型的传统审计流程遵循以下步骤： -## Lesson: Audit Methods +- 审核员向收购方发送问题，以便更好地了解工作。 +- 收购方做出回应，让审计师更好地了解审计范围和审计参数。 +- 审核员根据答复提供报价。 +- 就报价达成一致。接下来是签署服务协议、工作说明书、保密协议等（请注意，所有数字中的“开始”均假设所有协议签署后审计过程实际开始。） +- 审核员可以通过安全的云上传或访问公司进行现场审核来访问目标代码。 +- 审计员扫描目标的源代码，清除任何误报，并评估结果。 +- 审计员生成报告并将其交付给客户。 +- 随后通过电话或面对面的会议与审核员一起审查结果并解决任何问题。 -**Overview** +这种方法在大多数审计服务提供商中都很常见，它允许有机会为同一审计工作收集多个投标，并能够根据您的要求选择最佳投标。 -Depending on what the auditors find during the initial acquisition discussion phase, they may have to rely on several types of tools (scanning, license identification, component management) to perform the audits. +为了使这种模式有效，目标公司必须愿意将代码传输给审计员或允许他们访问他们的办公室以完成现场工作。 -There are two audit methods: +### 9.4.2 自己动手 (DIY) 审计 -1. Traditional audit, in which the auditor gets complete access to all the code and executes the audit either remotely or on site. -2. "Do It Yourself" audit, where the target company or the acquirer performs most of the actual audit work themselves using the tools with the option for a random verification of results from the auditing company. +![Image description](diy-audit.png) -**Traditional Audit** +Do-It-Yourself (DIY) 审计为收购方或目标公司提供了对合规云工具的限时访问，使他们能够自己运行扫描。然后，他们可以通过完全访问知识库和所有报告工具在内部执行审计。 -![Traditional Audit](traditional-audit.png) +对于拥有足够经验来解释扫描结果和建议补救程序的内部员工的公司来说，这是一种特别有趣的方法。对于每年经历多次并购过程的公司来说，它可以很快变得更具成本效益。审计工具服务提供商可以进行独立认证以验证结果，进一步确保审计的完整性。 -This method is called traditional, because it's the original method of source code scanning for open source compliance purposes. Traditional audits are those where a compliance auditor from a third-party auditing company gets access to the source remotely via a cloud system or physically while visiting on site and performs the source code scan. +这种方法有几个优点，例如能够在需要时立即开始审核，因为它使用内部资源并且不依赖于第三方审核员的可用性。这种方法可能会缩短时间并减少外部成本来源。 -Please note that the process may vary slightly from one service provider to another. A typical traditional audit process follows these steps: +任何合规性问题都可以立即解决，因为它是由可以直接访问代码并可以直接应用修复程序的人员进行的。最后，审计可以由审计工具的提供者进行验证，以确保正确性和完整性。 -- Auditor sends questions to the acquirer to have a better understanding of the job. -- Acquirer responds, allowing the auditor to have a better understanding of the scope and audit parameters. -- Auditor provides a quote based upon the responses. -- Agreement is reached on the quote. Next is signing the service agreement, statement of work, non-disclosure agreement, etc. (Please note that "Start" in all figures assumes an actual start of the audit process when all agreements have been signed.) -- Auditor is granted access to the target's code via secure cloud upload, or through a visit to the company for an on-site audit. -- Auditor scans the target's source code, cleans up any false positives, and evaluates the results. -- Auditor generates the report and delivers it to the client. -- A call or a face-to-face meeting follows to review the results with the auditor and address any questions. +### 9.4.3 最终审计报告说明 -This method is common across most audit service providers, and it allows the opportunity to collect multiple bids for the same audit job and the ability to choose the best bid given your requirements. +许多审计工具也可以调整以突出潜在问题。 仔细查看结果后，您可能会发现许多结果都不是问题，但您应该预料到初始报告中可能会出现大量“噪音”。 -For this model to work, the target company must be willing to transfer the code to the auditors or allow them to visit their offices to complete the job on-site. +噪音可能来自代码树中但未使用的剩余代码之类的东西。 因此，初始报告可能很长，您应该准备好花时间过滤报告以找出真正的问题。 -**Do-It-Yourself (DIY) Audit** +请注意，通常按需提供软件包数据交换 (SPDX) 一致性报告。 因此，如果您希望您的审计服务提供商提供这样的报告，您将需要请求它，如果您已经投资了与 SPDX 兼容的工具，这将使导入和跟踪您的审计结果变得更加容易。 - +### 9.4.4 获取前和获取后的补救措施 -![DIY Audit](diy-audit.png) +到此为止，收购公司应该清楚目标公司如何使用和管理开源软件，以及他们在满足开源许可义务方面取得了多大的成功。收购者和目标应该使用此信息协商任何开源遵从性问题的补救措施。 -The Do-It-Yourself (DIY) audit provides the acquirer or the target company time-limited access to the compliance cloud tools, enabling them to run the scan themselves. They can then perform the audits internally with complete access to the knowledge base and all reporting facilities. +如果在审计中发现任何问题，有几个选项可以解决这些问题，作为挂起事务的一部分。第一种选择是简单地删除任何违规代码。如果开源软件只是增加专有代码，那么完全消除它是可能的。另一种选择是围绕违规组件进行设计，或者使用洁净技术重写任何代码。 -This is an approach that is particularly interesting for companies that have in-house employees with sufficient experience to interpret scan results and suggest remediation procedures. It can quickly become more cost-effective for companies that go through the M&A process several times per year. An independent certification can be performed by the auditing tools service provider to verify the findings, to further secure the integrity of the audit. +如果代码部分确实是必要的，或者它之前已经发布过，那么剩下的唯一选择就是使代码符合要求。每个期权的成本可以用来确定目标的估值。无论选择何种方案，关键是要确定参与合并开放源代码的个人，并让他们参与补救工作。他们可能拥有有助于解决问题的额外文档或知识。 -This approach has several advantages, such as the ability to start the audit as soon as it's needed because it uses internal resources and is not dependent on the availability of third-party auditors. This approach potentially shortens the timeline and reduces an external source of cost. +## 9.5 作为收购方准备审计 -Any compliance problem can be addressed immediately, because it is conducted by the people who have direct access to the code and can apply fixes directly. Finally, the audit can be verified by the provider of the audit tool to ensure correctness and completeness. +### 9.5.1 考虑您的需求 -**Final Audit Report Notes** +作为收购方，您必须在委托审计之前采取行动并做出决定，并且在收到结果后您还有额外的义务。 因此，重要的是考虑您的需求，以及前面提到的哪种审计方法最适合您的组织和特定情况。 -Many auditing tools can also be tuned to highlight potential issues. After viewing the results carefully, you might find many of the results to be non-issues, but you should expect the potential for a lot of "noise" in the initial reports. +就审计结果而言，确定组织最关心什么也同样重要。 源代码审计报告可能会提供大量信息，具体取决于扫描代码的复杂性。 因此，在获得结果之前确定哪些许可证和用例被认为是关键的很重要。 -The noise may come from things like leftover code that is in the code tree but not used. Therefore, the initial report may be lengthy, and you should be prepared to invest time to filter the report to find the real issues. +在审核前后明确您的需求不仅会使审核过程更顺畅，而且从长远来看也更具成本效益。 -Note that a Software Package Data Exchange (SPDX) conformant report is usually provided on demand. Therefore, if you would like your audit service provider to provide such a report, you will need to request it, and if you've already invested in SPDX-compatible tooling, this will make importing and tracking your audit results much easier. +### 9.5.2 提出正确的问题 -**Pre and Post Acquisition Remediation** +开源审计报告提供了大量有关目标源代码和所涉及许可证的信息。但是，许多其他数据点需要进一步调查，以澄清或确认与合规性相关的问题。在本节中，我们提供了一系列问题，以此作为起点来确定对您而言重要的内容，以及您应该向目标公司解决哪些问题。 -By this point, the acquiring company should have a clear idea how the target uses and manages open source software and how successful they've been at satisfying their open source license obligations. The acquirer and target should use this information to negotiate remediation for any open source compliance issues. +- 目标公司是否使用了可能危及目标公司或收单方知识产权的许可代码？ +- 是否有任何来源不明和/或许可证不明的代码片段？ +- 目标的开源合规实践是否足够成熟和全面？ +- 目标公司是否跟踪其开源组件中的已知漏洞？ +- 在分发产品时，目标是否提供所有必要的材料来满足开源许可义务（书面报价、各种必要的通知和适用的源代码）？ +- 目标公司的合规流程是否与开发速度保持一致以满足产品发布计划？ +- 目标是否有适当的流程来及时响应对源代码的请求？ -If any issues are uncovered in the audit, there are a few options for resolving them as a part of the pending transaction. The first option is to simply remove any offending code. If the open source software only augments proprietary code, it may be possible to eliminate it entirely. Another option is to design around the offending component, or rewrite any code using cleanroom techniques. +### 9.5.3 确定要解决的项目 -If the section of code is truly essential or if it has been previously distributed, the only remaining option is to bring the code into compliance. The cost of each option can be used when determining the valuation of the target. Whatever option is chosen, it's crucial to identify the individuals who participated in incorporating the open source code, and to get them involved in the remediation effort. They might have additional documentation or knowledge that can be useful in resolving issues. +在某些情况下，开源审计可能会发现收购方不可接受的许可或合规实践实例。 然后，收单方可以请求减轻这些情况，作为结束交易的条件。 -## Lesson: Preparing for an Audit as The Acquiring Company +例如，目标公司可能使用使用许可证 A 的代码组件，但收购公司有严格的政策禁止使用许可证 A 下许可的任何源代码。 -**Think About Your Needs** +在这种情况下，双方需要讨论并找出可能的解决方案。 -As an acquirer, you must take action and make decisions before the audit is commissioned and you have additional obligations after you receive the results. Therefore, it's important that you consider your needs, as well as which of the audit methods mentioned earlier would work best for your organization and particular situation. +### 9.5.4 制定收购后合规改进计划 -It's equally important that you determine what you most care about as an organization in terms of audit results. The report from the source code audit may provide a significant amount of information, depending on the complexity of the scanned code. Therefore, it's important to identify which licenses and use-cases are regarded as critical ahead of getting the results. +当收购方是一家大公司，收购一家将继续作为子公司运营的小型初创公司时，制定合规改进计划尤为重要。 在这种情况下，收购方通常会帮助目标公司建立正式的合规政策和流程，提供有关其自身实践的培训，并提供持续的指导和支持。 -Being clear about your needs both before and after the audit will not only make the audit process smoother, but also more cost-efficient in the long run. +也可能有机会通过改进工具/流程和/或人员配备来协助收购。 -**Ask the Right Questions** +## 9.6 准备作为收购目标的审计 -The open source audit report offers a lot of information about the target's source code and the licenses involved. However, many other data points will require further investigation in order to clarify or confirm compliance-related concerns. In this section, we offer a collection of questions as a starting point to frame what is important to you, and what questions you should address with the target company. +### 9.6.1 做好准备 -- Has the target used code with licenses that could jeopardize the IP of the target or acquirer? -- Are there any code snippets with unknown origin and/or unknown license? -- Are the target's open source compliance practices sufficiently mature and comprehensive? -- Does the target company track known vulnerabilities in their open source components? -- When distributing products, does the target provide all necessary materials to satisfy open source license obligations (written offer, various required notices, and source code when applicable)? -- Does the target company's compliance process align with the speed of development to meet product release schedules? -- Does the target have a process in place to respond to requests for source code in a timely manner? +如果您准备好了，通过开源合规性审核并不难。但是，如果您仅在收购方表现出兴趣后才开始准备，这种情况就不太可能发生。这些活动旨在与您的日常业务和发展活动齐头并进。目标是确保公司跟踪所有开源组件并遵守因使用开源组件而产生的开源许可义务。如果您的公司成为公司交易的目标，这些相同的措施可能会大有帮助，因为它们最大限度地降低了意外风险。 -**Identify Items to be Resolved** +正如您将在接下来的几页中看到的，这些实践与我们在本模块中学到的内容一致。 -In some cases, an open source audit may reveal instances of licenses or compliance practices that are not acceptable to the acquirer. The acquirer can then request these instances to be mitigated as a condition for closing the transaction. +### 9.6.2 了解您的代码中的内容 -For instance, the target company may use a code component that uses License A, but the acquiring company has a strict policy against using any source code licensed under License A. +了解代码中的内容是合规性的黄金法则。您需要维护所有软件组件的完整软件清单，包括它们的来源和许可证信息。这包括由您的组织创建的软件组件、开源组件和源自第三方的组件。最重要的一点是有一个识别和跟踪开源组件的过程。您并不总是需要复杂的合规计划，但是，您应该具备五个基本要素：政策、流程、员工、培训和工具。 -In such a situation, both parties will need to discuss and figure out a possible solution. +### 9.6.3 政策和流程 -**Create a Post-acquisition Compliance Improvement Plan** +![Image description](policy-process.png) -Creating a compliance improvement plan is especially important when the acquirer is a large company buying a smaller startup that will continue to operate as a subsidiary. In this scenario, the acquirer often helps the target establish a formal compliance policy and process, provides training on their own practices, and offers ongoing guidance and support. +这个数字重申了我们已经涵盖的一些内容，但在这里重新审视它很重要。 -There may also be an opportunity to assist the acquisition with improved tooling/processes and/or staffing. +开源合规政策是一套管理开源软件（使用和贡献）的规则。流程是关于公司如何每天实施这些规则的详细规范。合规政策和流程管理开源软件的使用、贡献、审计和分发的各个方面。 -## Lesson: Preparing for an Audit as An Acquisition Target +此图说明了一个示例合规性流程，其中包含每个软件组件在构建产品或软件堆栈时作为尽职调查的一部分将经历的各个步骤。 -**Be Prepared** +- 识别所有传入的源代码 +- 审计源代码 +- 解决审计发现的任何问题 +- 完成适当的审查 +- 获得使用开源的批准 +- 在软件清单中注册开源 +- 更新产品文档以反映开源使用情况 +- 对分发前的所有步骤进行验证 +- 分发源代码并执行与分发相关的最终验证 -Passing an open source compliance audit is not hard if you're prepared. However, it is very unlikely to happen if you begin preparing only once an acquirer shows interest. These activities are meant to go hand-in-hand with your daily business and development activities. The objective is to ensure the company tracks all open source components and respects open source license obligations resulting from use of open source components. These same measures can be of great help if your company becomes a target for a corporate transaction, as they minimize the risk of surprises. +该过程的输出是您可以发布的开源 BoM，以及一份书面报价和各种版权、许可和归属通知，以履行您的 BoM 中组件的法律义务。 -As you'll see in the next few chapters, these practices are consistent with what we've learned to this point in this module. +有关开源合规性流程的详细讨论，请下载由 Linux 基金会出版的免费电子书《企业中的开源合规性》。 -**Know What's In Your Code** +### 9.6.4 工作人员 -Knowing what's in your code is the golden rule of compliance. You need to maintain a complete software inventory for all software components including their origin and license information. This covers software components created by your organization, open source components, and components originating from third parties. The most important point is having a process for identifying and tracking open source components. You don't always need a complex compliance program, however, you should have five basic elements: policy, process, staff, training, and tools. +在大型企业中，开源合规团队是一个由不同个人组成的跨学科团队，其任务是确保开源合规性。核心团队通常称为开源审查委员会 (OSRB)，由来自工程和产品团队的代表、一名或多名法律顾问以及一名合规官组成。 -**Policy and Process** +扩展团队由多个部门的不同人员组成，他们持续为合规工作做出贡献：文档、供应链、企业发展、IT 和本地化。但是，在较小的公司或初创公司中，这可能就像由法律顾问支持的工程经理一样简单。 -![Policy and Process](policy-process.png) +### 9.6.5 培训 -This figure restates some of what we've already covered, but it's important to revisit it here. +教育是合规计划的重要组成部分，可帮助确保员工充分了解管理开源软件使用的政策。提供开源和合规培训的目标是提高对开源政策和策略的认识，并建立对开源许可问题和事实的共同理解。它还应涵盖将开源软件纳入产品和/或软件组合的商业和法律风险。 -The open source compliance policy is a set of rules that govern the management of open source software (both use of and contribution to). Processes are detailed specifications as to how a company will implement these rules on a daily basis. Compliance policies and processes govern various aspects of using, contributing, auditing, and distribution of open source software. +正式和非正式的培训方法都可用。正式的方法包括讲师指导的培训课程，员工必须通过知识考试才能通过课程。作为新员工入职培训的一部分，非正式方法包括网络研讨会、棕色包研讨会和向新员工介绍。 -This figure illustrates a sample compliance process, with the various steps each software component will go through as part of the due diligence as you build your product or software stack. +### 9.6.6 工装 -1. Identify all incoming source code -2. Audit source code -3. Resolve any issues uncovered by the audit -4. Complete appropriate reviews -5. Receive approval to use open source -6. Register open source in the software inventory -7. Update product documentation to reflect open source usage -8. Perform verification to all steps previous to distribution -9. Distribute source code and perform final verifications in relation to distribution +到目前为止，您已经在本模块中了解到，有许多不同类型的工具可以在合规流程中使用。要记住的重要一点是，工具不能替代良好的流程，知识渊博的员工根据政策和工具提供的数据做出决策。 -The output of the process is an open source BoM that you can publish, along with a written offer and various copyright, license and attributions notices fulfilling the legal obligations of the components in your BoM. +考虑对您的工具采用“开源”方法也很重要 - 对现有工具进行持续评估，以及在必要时进行调整的能力对于维持健康的合规计划至关重要。 -For a detailed discussion on the open source compliance process, please download the free e-book [_Open Source Compliance in the Enterprise_](https://www.linuxfoundation.org/resources/publications/open-source-compliance-in-the-enterprise/), published by The Linux Foundation. +### 9.6.7 合规 -**Staff** +如果您发布了包含开源软件的产品（无论是有意还是无意），您都需要遵守管理这些软件组件的各种许可证。 因此，了解代码中的内容非常重要，因为完整的材料清单使合规性变得更加容易。 -In large enterprises, the open source compliance team is a cross-disciplinary group consisting of various individuals tasked with the mission of ensuring open source compliance. The core team, often called the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and a compliance officer. +合规性不是一项简单的任务，它因产品而异，具体取决于许可证和代码结构。 在较高的层面上，合规意味着您： -The extended team consists of various individuals across multiple departments that contribute on an ongoing basis to the compliance efforts: Documentation, Supply Chain, Corporate Development, IT, and Localization. However, in smaller companies or startups, this can be as simple as an engineering manager supported with a legal counsel. +- 跟踪所有开源软件的使用。 +- 为产品发货图像中的所有软件编译最终的开源 BoM。 +- 履行开源许可证的义务。 +- 每次发布软件更新时重复该过程。 +- 快速、认真地回应合规查询。 -**Training** +### 9.6.8 了解最新版本的安全性 -Education is an essential building block in a compliance program, to help ensure that employees possess a good understanding of policies governing the use of open source software. The goal of providing open source and compliance training is to raise awareness of open source policies and strategies, and to build a common understanding of the issues and facts of open source licensing. It should also cover the business and legal risks of incorporating open source software in products and/or software portfolios. +全面合规计划的好处之一是可以更轻松地找到具有不安全版本的开源组件的产品并替换它们。大多数源代码扫描工具现在提供标记旧软件组件中披露的安全漏洞的功能。 -Both formal and informal training methods are available. Formal methods include instructor-led training courses where employees have to pass a knowledge exam to pass the course. Informal methods include webinars, brown bag seminars, and presentations to new hires as part of the new employee orientation session. +升级开源组件时的一个重要考虑因素是始终确保该组件保留与先前版本相同的许可证。开源项目偶尔会更改主要版本的许可证。鼓励公司与开源项目社区合作，以帮助避免他们使用具有安全漏洞的版本的情况。 -**Tooling** +积极参与您使用的所有开源项目是不合理或不可行的，因此需要一定程度的优先级来确定最关键的组件。不同级别的参与范围从加入邮件列表和参与技术讨论，到贡献错误修复和小功能，再到做出重大贡献。至少，对于从事特定开源项目的公司开发人员来说，订阅和监控与安全漏洞和可用修复相关的报告的邮件列表是有益的。 -As you've already learned so far in this module, there are many different types of tools and can be utilized in the compliance process. An important thing to remember is that the tools are no substitute for good process, and knowledgeable staff making decisions based on policies and the data provided by the tools. +### 9.6.9 衡量您的合规工作 -It's also important to consider taking an "open source" approach to your tooling as well - continual evaluation of the tools in place, and the ability to pivot when necessary is critical to maintain a healthy compliance program. +对于各种规模的组织来说，最简单、最有效的第一步是参与 OpenChain 项目（前面提到过）并获得“OpenChain Conformant”状态。这是通过在线或手动填写一系列问题来完成的。 -**Be in Compliance** +用于 OpenChain 一致性的问题有助于确认组织已经创建了开源软件合规性流程或政策。 OpenChain 是一个行业标准，类似于 ISO 9001。它专注于“大局”，为每个组织提供精确的流程和政策实施。 -If you have shipped products containing open source software—whether intentionally or not—you will need to comply with the various licenses governing those software components. Hence the importance of knowing what's in your code, because a complete bill of materials makes compliance much easier. +OpenChain Conformance 表明存在开源合规流程或政策，并且可以在供应商或客户要求时共享更多详细信息。 OpenChain 旨在在全球供应链中的组织之间建立信任。 -Being in compliance is not a simple task, and it varies from product to product based upon the licenses and the structure of the code. At a high level, being in compliance means that you: +### 9.6.10 结论 -1. Track all use of open source software. -2. Compile a finalized open source BoM for all software in the shipping image of products. -3. Fulfill the obligations of the open source licenses. -4. Repeat the process every time you issue a software update. -5. Respond quickly and seriously to compliance inquiries. +开源尽职调查通常是并购交易中需要成功完成的一长串任务中的一项。 然而，鉴于软件和潜在知识产权风险的核心作用，它仍然是一般尽职调查工作的一个重要方面。 -**Keep Up with Latest Release for Security** +尽管开源尽职调查似乎是一个漫长的过程，但它通常可以很快完成，特别是如果双方都做好了准备，并与快速的合规服务提供商合作。 -One of the benefits of a comprehensive compliance program is that it's easier to find products with insecure versions of open source components and replace them. Most source code scanning tools now provide functionality to flag security vulnerabilities disclosed in older software components. +### 9.6.11 你如何做好准备? -One important consideration when upgrading an open source component is to always ensure that the component retains the same license as the previous version. Open source projects have occasionally changed licenses on major releases. Companies are encouraged to engage with open source project communities to help avoid situations where they are using a version with security vulnerabilities. +如果你是目标，你可以通过确保你的开发和业务流程包括: -It is not reasonable or feasible to be active in all of the open source projects you use, therefore a certain level of prioritization is needed to identify the most critical components. The various levels of engagement range from joining mailing lists and participating in the technical discussions, to contributing bug fixes and small features, to making major contributions. At minimum, it is beneficial for corporate developers working on a specific open source project to subscribe to and monitor the mailing list for reports related to security vulnerabilities and available fixes. +- 识别所有内部和外部软件的来源和许可。 +- 跟踪开发过程中的开源软件(组件和代码片段)。 +- 对进入构建的新代码或更新代码执行源代码审查。 +- 当产品交付或软件更新时，履行许可义务。 +- 为员工提供开源遵从性培训。 -**Measure Your Compliance Efforts** +如果你是收购方，你应该知道要寻找什么，并具备快速解决问题的技能: -The easiest and most effective first step for organizations of all sizes is to engage with the OpenChain Project (mentioned earlier) and to obtain "OpenChain Conformant" status. This is done by filling out a series of questions either [online](https://certification.openchainproject.org/) or manually. +- 与目标公司一起决定使用合适的审计方法，以及聘请哪一家第三方进行审计。 +- 注意，有些不具备盲测试的能力，有些不支持DIY，还有一些不具备发现代码片段的能力。 +- 如果可能的话，获得多个投标的审计和了解更多关于您的审计服务提供商。这一步不只是关于成本，而是关于获得精确的输出，以帮助您解决可能存在的任何问题。确保你有内部专家对每个投标进行平等的比较，并包括所有审计参数，如: + - 审核方法、输入和输出 + - 与目标公司和收购公司的主要联系人迅速讨论出现的问题 + - 时间安排和物流，特别是如果涉及到现场访问 + - 机密性参数 + - 代码漏洞和版本控制分析 + - 成本，流程正常，加急 -The questions used for OpenChain Conformance help to confirm that an organization has created processes or policies for open source software compliance. OpenChain is an industry standard, similar to ISO 9001. It is focused on the "big picture," with precise processes and policy implementations up to each individual organization. +开源遵从性是一个持续的过程。维护良好的开源遵从实践使公司能够准备好任何软件转手的场景，从可能的收购、销售或产品或服务发布。出于这个原因，我们强烈鼓励公司投资构建和改进他们的开源遵从性程序。 -OpenChain Conformance shows that open source compliance processes or policies exist, and that further details can be shared when requested by a supplier or customer. OpenChain is designed to build trust between organizations across the global supply chain. - -**Conclusion** - -Open source due diligence is generally one item in a long list of tasks that need to be successfully completed in an M&A transaction. However, it is still an important aspect of the general due diligence exercise given the central role of software and potential IP risks. - -Although open source due diligence may seem like a lengthy process, it often can be completed quickly, especially if both parties are prepared, and working with a swift compliance service provider. - -**How can you be prepared?** - -If you are the target, you can maintain proper open source compliance practices by ensuring your development and business processes include: - -- Identifying the origin and license of all internal and external software. -- Tracking open source software within the development process (components and snippets). -- Performing source code reviews for new or updated code entering the build. -- Fulfilling license obligations when a product ships or when software is updated. -- Offering open source compliance training to employees. - -If you are the acquirer, you should know what to look for and have the skills on-hand to address issues quickly: - -- Decide with the target company on the appropriate audit method to use, and which third party to engage for the audit. -- Note that some don't have ability to do blind testing, some do not support the DIY, and others do not have the ability to discover code snippets. -- If possible, get multiple bids for the audit and learn more about your audit service providers. This step is not just about the cost, but about having the precise output to help you address any concerns you may have. Make sure you have the internal expertise to compare each bid equally and that they include all audit parameters, such as: - - Audit method, inputs and outputs - - Primary contact persons at target and acquirer for speedy discussions of issues that arise - - Timeline and logistics especially if it involves an on-site visit - - Confidentiality parameters - - Code vulnerabilities and version control analysis - - Cost, normal process and expedited - -Open source compliance is an ongoing process. Maintaining good open source compliance practices enables companies to be prepared for any scenario where software changes hands, from a possible acquisition, a sale, or product or service release. For this reason, companies are highly encouraged to invest in building and improving upon their open source compliance programs. diff --git a/sources/OSPO-101/module6/README.md b/sources/OSPO-101/module6/README.md index ead9638..17251fa 100644 --- a/sources/OSPO-101/module6/README.md +++ b/sources/OSPO-101/module6/README.md @@ -1,482 +1,475 @@ --- -status: collected +status: translated title: "OSPO 101 Training Modules - Module 6" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module6/README.md --- +# 1. 课程简介 -# Understanding Upstream Open Source Projects +## 1.1 简介 -## Lesson: Introduction +在本节中，我们将解释上游在开源项目上下文中的含义，并讨论治理模型及其对您的贡献策略的影响。 -### Section Overview +## 1.2 学习目标 -In this section, we'll explain what upstream means in the context of open source projects and discuss governance models, and their effect on your contribution strategies. +在本节结束时，您应该能够： -### Learning Objectives +- 描述什么是上游开源项目及其重要性 +- 解释一些典型的治理模型和成功贡献的策略 -By the end of this section, you should be able to: +# 2. 上游开源简介 -- Describe what an upstream open source project is and why it's important -- Explain some typical governance models and strategies for successful contributions +## 2.1 我们所说的上游是什么意思？ -## Lesson: Introduction to Upstream Open Source +我们已经在本模块中使用了上游这个术语，但这是什么意思？ -### What Do We Mean by Upstream? +这是一个快速定义： -We've used the term _upstream_ already in this module, but what do we mean by that? + **上游（名词）** -Here's a quick definition: +衍生品所基于的原始开源软件项目 -**Upstream (noun)** +这个术语来自这样一种想法，即水和它携带的货物漂浮在下游并惠及那些接收它的人。 -The originating open source software project upon which a derivative is built + **上游（动词）** -This term comes from the idea that water and the goods it carries float downstream and benefit those who are there to receive it. +“将更改推送到上游项目”的简写方式，即将您对源代码程序所做的更改贡献回专用于该程序的原始项目。 -**To upstream (verb)** +如果你在供应链的背景下考虑上游，它会是这样的： -A short-hand way of saying "push changes to the upstream project", i.e. contribute the changes you made to the source code program back to the original project dedicated for that program. +![Image description](supply-chain-funnel.png) -If you think about upstream in the context of a supply chain, it would like like this: +## 2.2 为什么要向上游贡献？ -![Open Source Supply Chain Funnel](supply-chain-funnel.png) +组织经常提出的最大问题是为什么还要从一开始就为上游做出贡献。 虽然只是消费而从不回馈似乎更容易，但您应该考虑做出贡献的原因有很多，包括： -### Why Should You Contribute Upstream? +- 公共开发从不考虑私有代码 +- 将您的更改集成到上游意味着其他人知道它们，并且可以围绕它们进行规划 +- 降低您自己的代码意外损坏的风险 - 如果您进行与上游项目不兼容的本地更改，则需要时间和资源来修复这些问题 +- 将变更集成到上游项目中可以减少构建成品的工作量 +- 贡献的代码经过审查，可能会吸引外部资源来更改您在上游项目中需要的更改 +- 贡献加强项目，让你有机会影响未来的项目方向 -The biggest question often asked by organizations is why even contribute upstream to begin with. While it may seem easier to just consume and never contribute back, there are many reasons why you should consider making the effort to contribute, including: +## 2.3 你什么时候应该贡献上游？ -- Private code is never considered in public development - - Integrating your changes upstream means others are aware of them, and can plan for and around them - - Reduces the risk of accidental breakage in your own code - if you make local changes which are incompatible with the upstream project, it takes time and resources to fix those issues -- Integrating changes into an upstream project reduces the amount of effort to build a finished product -- Contributed code is reviewed and may attract external resources to changes you'll need in the upstream project -- Contributions strengthen the project and give you an opportunity to influence future project directions +刚接触开源的组织往往在合适的时间开始为上游做出贡献而苦恼。 以下指南很好地概述了上游贡献的原因/时间： -### When Should You Contribute Upstream? +- 当保持代码与上游项目同步的成本（时间或美元）超过单独工作的便利性时 +- 当您希望其他人（包括客户）使用您的代码时 +- 当您希望您的代码成为事实上的标准，或推动主线项目的采用时 +- 如果您预计在即将推出的产品中重复依赖某个代码库来补充上游项目 -Organizations new to open source often struggle with when the right time is to start contributing upstream. The following guidelines give a good overview of reasons/timing for upstream contributions: +## 2.4 示例：没有上游的开发 -- When the costs (time or $) of keeping your code in sync with the upstream project exceed the convenience of working alone -- When you want your code to be used by others (including customers) -- When you want your code to become a defacto standard, or drive adoption of the mainline project -- If you anticipate relying on a certain codebase repeatedly in upcoming products that complements the upstream project +为了让您更好地了解如果您没有有效地参与上游项目会发生什么，这里有一个图形示例： -### Example: Development Without Upstreaming +![Image description](dev-without-upstreaming.png) -To give you a better perspective on what can happen if you don't effectively participate in an upstream project, here's a graphical example: +如您所见，当您需要引入上游开源项目的“主线”时，例如当您需要的安全漏洞或功能发布时，它会变得非常繁重。 定期跟上上游项目的主要版本意味着您正在逐步支付该成本，而不是一次性支付。 -![Development Without Upstreaming](dev-without-upstreaming.png) +## 2.5 示例：上游开发 -As you can see, it can become quite burdensome when you need to bring in the "mainline" of an upstream open source project, for example when a security bug or feature that you need is released. Keeping up with major releases of an upstream project on a regular basis means that you are paying that cost incrementally, instead of all at once. +作为一个反例，以下是采用有效上游贡献策略的开发情况： -### Example: Development With Upstreaming +![Image description](dev-with-upstreaming.png) -As a counter-example, here's what development looks like with an effective upstream contribution strategy: +这里要注意的重要一点是应用较少的自定义补丁，因为在频繁地进行上游贡献并更好地与上游项目保持同步时，可以更快地发现问题和集成问题。 -![Development With Upstreaming](dev-with-upstreaming.png) +## 2.6 上游治理模型 -The important thing to note here is the application of fewer custom patches because problems and integration issues can be found more quickly when making frequent upstream contributions and keeping better in sync with the upstream project. +上游开源项目使用的治理模型并不缺乏。 它们因集权程度、一个或几个组织实体的强大影响以及受民主启发的决策机制和领导选择的存在而异。 -### Upstream Governance Models +模型的选择和执行的好坏对项目的质量，以及它被采用和发展、改进和成功的速度有着深远的影响。 没有一刀切的模型，每个模型都有其支持者和反对者。 此外，不同的项目有不同的内在需求，一种特定的模式可能会更好地满足这些需求。 -There is no shortage of governance models used by upstream open source projects. They differ according to the degrees of centralization, strong influence by one or a few organizational entities, and existence of democratically-inspired decision mechanisms and leadership selection. +在接下来的页面中，我们将介绍最常用的治理模型。 -The choice of model and how well it is executed have profound influences on the quality of a project, as well as how quickly it is adopted and evolves, improves and succeeds. There is no one-size-fits-all model and each has its advocates and detractors. Furthermore, different projects have different inherent needs, which may be better satisfied by one particular model. +### 2.6.1 公司主导的治理 -In the following pages, we'll cover the most often used governance models. +公司主导的项目有一个基本封闭的过程，具有以下特点： -### Company Led Governance +- 发展是由一个公司或组织的利益强烈引导的 +- 一个实体控制软件设计、发布 +- 可能会也可能不会征求贡献、补丁、建议等。 +- 内部讨论、争议，可能不会播出太多 +- 下一个软件版本的确切内容尚不确定 +- 发布后，所有软件都完全开放 -Company-led projects have a mostly-closed process with the following characteristics: +示例：Google Android、Red Hat Enterprise Linux (RHEL) -- Development is strongly led by one corporate or organizational interest -- One entity controls software design, releases -- May or may not solicit contributions, patches, suggestions etc. -- Internal discussions, controversies, may not be aired very much -- Exactly what will be in next software release not definitively known -- Upon release, all software is completely in the open +可以想象，很难影响这些项目的方向，除非为这些工作的上游项目做出贡献——例如，Linux 内核是 Google Android 和 Red Hat Enterprise Linux 的上游，并且在那里获得了接受的功能（ 如果合适）是影响 Android 和 RHEL 的一种方式。 -Examples: **Google Android**, **Red Hat Enterprise Linux (RHEL)** +### 2.6.2 仁慈的独裁者 -As you can imagine, it can be hard to influence direction of these projects except by making contributions to projects further upstream from these efforts - for example, the Linux kernel is upstream from both Google Android and Red Hat Enterprise Linux and getting features accepted there (if appropriate) is one way to influence Android and RHEL. +具有这种治理类型的项目通常由一个或几个关键人物强有力地领导。 它们还具有以下特点： -### Benevolent Dictator +- 一个人对每一个决定都有压倒一切的影响 +- 项目的质量取决于仁慈的独裁者的质量 +- 可以避免无休止的讨论并加快步伐 +- 随着项目的发展，成功在很大程度上取决于独裁者的能力： +- 处理许多贡献者 +- 使用健全、可扩展的版本控制系统 +- 任命子系统维护人员并与之合作 +- 仁慈的独裁者的角色可能是社会和政治的，而不是结构性的：分叉随时可能发生 +- 随着项目的成熟，维护者编写的代码越来越少 -Projects with this type of governance typically have the strong leadership of one or a few key individuals. They also have the following characteristics: +示例：Linux 内核 -- One individual has overriding influence in every decision -- Project's quality depends on that of the benevolent dictator(s) -- Can avoid endless discussions and lead to quicker pace -- As project grows, success depends critically on dictator's ability to: - - Handle many contributors - - Use a sane, scalable, version control system - - Appoint and work with sub-system maintainers -- Benevolent dictator's role may be social and political, not structural: Forks can occur any time -- Maintainers write less and less code as projects mature +### 2.6.3 理事会 -Example: **Linux kernel** +具有理事会结构的项目具有以下特点： -### Governing Board +- 一个机构（组）在公开邮件列表上进行讨论 +- 关于设计、发布日期等的决定是集体做出的 +- 关于谁可以贡献、如何接受补丁和新软件的决定由管理机构做出 +- 在治理结构、组织规则、所需的共识程度等方面存在很大差异。 +- 倾向于不那么频繁地发布，但希望调试良好的版本 -Projects with a Governing Board structure have the following characteristics: +示例：FreeBSD、Debian -- A body (group) carries out discussions on open mailing lists -- Decisions about design, release dates, etc., are made collectively -- Decisions about who can contribute, how patches and new software are accepted, are made by governing body -- Much variation in governing structures, rules of organization, degree of consensus required, etc. -- Tends to release less frequent, but hopefully well debugged versions +具有这种治理形式的项目可以由业余爱好者或企业开发人员组成，但与基金会/联盟模式相比，其公开的企业影响力往往要小一些（见下文）。 -Examples: **FreeBSD**, **Debian** +### 2.6.4 基金会/财团 -Projects with this form of governance can be composed of either hobbyists or corporate developers, but tend to have less overt corporate influence than the Foundation/Consortium model (covered next). +基金会或联盟内的项目混合了先前讨论的治理模型，通常具有以下独特特征： -### Foundation/Consortium +- 业务/战略治理监督委员会/董事会 +- 提供整体业务和战略方向 +- 成员通常由项目的企业赞助商组成 +- 单独的技术指导委员会进行技术决策 +- 用于技术讨论的公共决策/邮件列表 +- 由企业赞助商技术资源组成的领导层 +- 能够任命/投票给非公司附属技术资源 +- 定期发布，测试/验收周期更长 -Projects within Foundations or Consortiums have a mix of the previously-discussed governance models, usually with the following unique characteristics: +示例：Open Stack、Kubernetes、Academy Software Foundation -- Business/strategic governance oversight committee/board - - Provides overall business and strategic direction - - Membership usually composed of corporate sponsors of the project -- Separate technical steering committees for technical decisions - - Public decisions/mailing lists for technical discussions - - Leadership composed of technical resources of corporate sponsors - - Ability to have non-corporate-affiliated technical resources appointed/voted on -- Regular releases with longer testing/acceptance cycles +我们将在未来的培训模块中更多地介绍 Foundations 和开源合作伙伴关系。 -Examples: **Open Stack**, **Kubernetes**, **Academy Software Foundation** +### 2.6.5 参与注意事项 -We'll have more to say about Foundations and open source partnerships in a future training module. +很多人问以上哪种治理模式最好，或者他们的组织应该参与哪个。现实是每种模式都有优点和缺点，但在很多情况下，你可能无法选择参与哪种模式，特别是如果该项目是您的产品或业务的核心。 -### Participation Considerations +作为一个组织，您应该考虑的最重要的事情是确保您拥有合适的人员配备（工程和领导力）以有效参与您需要使用的项目的任何模型。许多组织面临的最大挑战是参与太多或很少的工程或管理资源。 -Many people ask which of the governance models above is best or which should their organization participate in. The reality is that each model has advantages and disadvantages, but in many cases, you may not have a choice of which model to participate in, especially if the project is one that is core to your product or business. +了解您的组织从项目中需要什么——如果您需要战略投入，做出持续的工程贡献以及资金支持或领导可能是您最好的选择。如果您主要是技术的消费者，只是偶尔需要做出上游贡献，那么采用主要由工程驱动的资源方法可能会更好。 -The biggest thing you should consider as an organization is making sure that you have the proper staffing (engineering and leadership) to participate effectively in whichever model the project you need is using. The biggest challenge many organizations face is participating with either too many or two few engineering or management resources. +# 3. 有效的上游贡献策略 -Understand what your organization needs from a project - if you need strategic input, making sustained engineering contributions as well as monetary support or leadership may be your best bet. If you are primarily a consumer of the technology with only the occasional need to make upstream contributions, having a primarily engineering-driven resourcing approach may work better. +## 3.1 简介 -# Section: Effective Upstream Contribution Strategies +在本节中，我们将讨论如何最有效地与上游开源项目合作，包括了解与开发社区互动的最佳方式、成功策略以及应避免的行为。 -## Lesson: Introduction +## 3.2 学习目标 -### Section Overview +在本节结束时，您应该能够： -In this section, we will discuss how to most effectively work with upstream open source projects, including understanding the best ways to engage with development communities, strategies for success, and what behaviors to avoid. +- 描述与上游社区有效合作的最重要因素 +- 解释成功的上游贡献的最佳实践 +- 了解您需要在组织中解决哪些流程和注意事项才能成为有效的上游贡献者 -### Learning Objectives +## 3.3 上游合作 -By the end of this section, you should be able to: +### 3.3.1 贡献的地方 -- Describe the most important factors in working effectively with upstream communities -- Explain best practices for successful upstream contributions -- Understand what processes and considerations you'll need to address in your organization to be an effective upstream contributor +在了解为上游项目做出贡献的重要性之后，下一个最重要的决定是找出您应该在何处做出贡献。正如我们在模块 2，开源业务战略中所述，从工程和业务角度清楚了解哪些开源项目对您很重要，这将有助于指导您做出这一重要决策。 -### Lesson: Upstream Collaboration +一般来说，您应该根据为您的组织提供最大整体价值的因素来评估开源项目和您的贡献，以及您必须花费多少工程资源来实现这些贡献。 -### Where to Contribute +一些重要的问题和考虑包括： -After understanding why it's important to contribute to upstream projects, the next most important determination is finding out **where** you should be contributing. As we covered in Module 2, Open Source Business Strategy, having a clear understanding from both an engineering and business perspective about what open source projects are important to you will help guide you in this important decision. +- 我们在组织内使用哪些开源项目？花一些时间来评估哪些开源项目已经在整个组织中使用，以确定哪些对您的业务具有战略意义。您可能希望将评估重点放在几个地方：关键业务基础设施（运营）、影响您发布产品能力的开发和部署工具，以及对面向客户的产品或服务很重要的软件。 +- 我们应该针对哪些项目做出贡献？大多数组织使用许多开源项目，因此确保您的计划只关注最重要的项目非常重要。仅仅因为一个项目不在目标列表中并不意味着人们不能为该项目做出贡献；这只是意味着它不是您组织的关键焦点。如果开源项目对您的业务至关重要，并且有可能导致严重停机或中断您为客户服务的能力，那么它可能是一个很好的贡献候选人。 -In general, you should be evaluating open source projects, and your contributions, based on what provides the most overall value for your organization, for the amount of engineering resources you'll have to spend to enable these contributions. +### 3.3.2 贡献什么 -Some important questions and considerations include: +除了应该为上游项目做出贡献之外，最重要的问题之一是“为什么这些贡献很重要？” -- **Which open source projects do we use within the organization?** Take some time to assess which open source projects are already in use across the entire organization to determine which ones are strategic to your business. A few places you might want to focus your assessment: critical business infrastructure (operations), development and deployment tools that impact your ability to release products, and software that is important for customer-facing products or services. -- **Which projects should we target for contribution?** Most organizations use many open source projects, so it's important to make sure that your plan focuses on just the most important ones. Just because a project isn't on the target list doesn't mean that people can't contribute to that project; it just means that it isn't a critical focus for your organization. If an open source project is critical to your business and has the potential to cause significant downtime or disruption to your ability to serve your customers, it's probably a good candidate for contributions. +很容易进入并开始谈论你计划做的所有伟大的事情，但不要忘记包含令人信服的论据，说明为什么这项工作对组织很重要和具有战略意义，以及你计划如何实施任何和所有战略价值的贡献。 -### What to Contribute +有时，这些贡献对于支持您正在构建的产品很重要，有时它们对于保持整个上游项目的强大和健康很重要，以便您可以在下游工作中依赖它。您还需要从上游项目的角度考虑这一点 - 您的计划贡献需要对上游项目的更广泛社区有价值。 -Other than where you should be contributing to upstream projects, one of the most important questions to ask is "**Why are these contributions important?**" +重要的是要避免提出可能对您的组织具有战略意义的贡献的不良行为，但仅对您自己的用例有用，并且通常不适用于整个上游项目社区。 -It's easy to jump in and start talking about all the great things you plan to do, but don't forget to include compelling arguments for why this work is important and strategic to the organization, as well as how you plan to parlay any and all contributions into strategic value. +### 3.3.3 如何贡献 -Sometimes the contributions are important to supporting a product you are building, and sometimes they are important just to keep the overall upstream project strong and healthy so that you can rely on it in your downstream efforts. You also need to consider this from the upstream project's point of view - your planned contributions need to be valuable to the wider community for the upstream project. +关于您如何为上游开源项目做出贡献的技术流程，有很多很好的资源，但是，让我们在高层次上集中讨论在考虑您的组织将如何做出贡献时可以使用的一些最佳实践。 -It's important to avoid the bad behavior of proposing contributions that may be strategic for your organization, but only useful for your own use cases, and not generally applicable to the whole upstream project community. +以下是您开始贡献之旅时需要考虑的一些事项： -### How to Contribute +- 采用“上游优先”的理念 +- 始终计划与主分支合并 + - Fork 和 side branch 都可以，只要有与上游合并的计划 +- 使内部开发工作与上游分支发布节奏保持一致 +- 要求正确记录所有代码，以便上游审查人员更好地理解，这可能有助于加快验收周期 +- 尽早关注发布并经常练习。不要构建庞大的代码库，然后决定将其上游化。共享设计、早期代码并在相互构建的较小的独立补丁中提交大量贡献。 +- 跟踪您选择不上游的代码：抓住每一个机会重新评估。如果您发现内部维护代码的大小呈上升趋势，则需要对先前的决定进行讨论和重新评估。 -There are many great resources for the technical process of how you contribute to upstream open source projects, but, let's concentrate at a high level here on some best practices you can use when considering how your organization will contribute. +### 3.3.4 有效的贡献政策 -Here are some things to consider as you start your contribution journey: +尽管将有效的合规政策作为开源战略的一部分实施很重要，但让您的法律和领导团队参与以帮助建立快速批准上游贡献的轻量级政策也很重要。 -- Adopt an "upstream first" philosophy -- Always plan to merge back with the main branch - - Forks and side branches are ok as long as there is a plan to merge with upstream -- Align internal development effort with the upstream branch release cadence -- Require all code to be properly documented to be better understood by upstream reviewers, which will likely contribute to a faster acceptance cycle -- Follow the release early and often practice. Don't build a huge code base and then decide to upstream it. Share design, early code and submit large contributions in smaller, independent patches that build on each other. -- Track the code you choose to not upstream: Reevaluate at every opportunity. If you spot an upward trend in the internal maintained code's size, this calls for a discussion and reevaluation of prior decisions. +这些政策不应该是关于规则和条例的，而应该更多是帮助人们成功地为开源项目做出贡献。如果人们有指导方针和清单，以确保他们拥有做出成功贡献所需的一切，而不会遇到许可或保密问题，这会有所帮助。 -### Effective Contribution Policies +特别是对于新的贡献者，在做出贡献之前，将内部审查流程作为一个安全的地方来获得反馈也很有帮助。 -Though it's important to have effective compliance policies implemented as part of your open source strategy, it's also critical that your legal & leadership teams be involved to help set up lightweight policies of fast approval of upstream contributions. +在许多情况下，贡献政策已经预定义了上游项目使用的已批准开源许可证列表，并与开发人员采取“沙盒”方法，如果他们为使用以下项目之一的项目这样做，则允许他们为上游项目做出贡献预先批准的许可证。 -These policies should be less about rules and regulations and more about helping people be successful in making contributions to open source projects. It can help if people have guidelines and checklists to make sure that they have everything they need to make a successful contribution without running into licensing or confidentiality issues. +目标是平衡开源的公司治理与促进与上游开发人员交互的流程。 -Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution. +### 3.3.5 人员配备注意事项 -In many cases, contribution policies have predefined lists of approved open source licenses used by upstream projects, and take a "sandbox" approach with developers, where they are allowed to contribute to upstream projects if they are doing so for a project using one of the pre-approved licenses. +人员配备是成功的上游贡献的关键因素。如果您的工程团队做出了一些小的上游贡献，您可能已经在您的组织中拥有相关的专业知识。但是，当您开始查看对您的业务至关重要的上游项目时，您需要确定您是否拥有相关的内部专业知识来做出持续贡献，或者您是否需要为此聘请。 -The goal is to balance corporate governance of open source with a process to facilitate interactions with upstream developers. +如果您必须从外部招聘，重要的是要确保找到不仅具备做出贡献的技能的人，而且还能够找到能够让社区接受上游贡献的人。 -### Staffing Considerations +招聘的一种方法是考虑从上游项目社区招聘关键开发人员和维护人员。请注意，这些人的需求量很大，因此您不仅要准备好提供适当的薪水，还要准备好让他们能够继续从事他们所参与的上游项目的工程文化。 -Staffing is a critical element to successful upstream contribution. You may already have relevant expertise in your organization, if you have engineering teams that have made some small upstream contributions. However, as you start to look at upstream projects that are critical for your business, you'll need to ascertain whether you have the relevant expertise in-house to make sustained contributions, or whether you need to hire for it. +目标是找到具有足够同行认可度以在社区中具有影响力的人。这通常有三个支柱：领域专业知识、开源方法和工作实践。您还需要将公司利益与个人利益结合起来：当高级开源开发人员的个人利益与给定项目中的公司利益不符时，很难激励高级开源开发人员工作。例如，Linux 内存管理专家可能对处理公司优先事项的文件系统不感兴趣。因此，找到一个兴趣匹配的人对于一段长久的关系来说是至关重要的。 -If you have to hire externally, it's important to make sure to find people with the skills not only to produce the contributions, but also people who are skilled at getting their upstream contribution accepted by the community. +### 3.3.6 时间表/时间注意事项 -One way to seed your hiring is to consider hiring key developers and maintainers from the upstream project community. Be aware that these people are in high demand, so you have to be prepared to offer not only an appropriate salary, but also an engineering culture that allows them to continue working on the upstream project that they are a part of. +在项目时间表中为上游贡献提供足够的时间至关重要。如果您的内部开发人员正在为上游做出贡献，则您需要在他们的日程安排中预算时间，以允许做出这些贡献。如果您正在聘请外部开源开发人员到您的组织中工作，并在您的产品上工作，您还需要考虑如何平衡他们的日程安排。 -The goal is to find people who have enough peer recognition to be influential in the community. There are typically three pillars to this: domain expertise, open source methodology, and working practices. You also need to align corporate interests with individual interests: it's very hard to motivate a senior open source developer to work when their personal interests don't meet with corporate interests in a given project. For example, a Linux memory management expert may not be interested in working on file systems, a corporate priority. Therefore, finding a match in interests is critical for a long lasting relationship. +招聘开源开发人员的核心原则是支持你的开源开发和上游活动。还期望他们应该在他们的专业领域支持产品团队。然而，产品团队利用他们的影响力试图通过让他们尽可能多地从事产品开发来劫持开源开发人员的时间并不少见。如果发生这种情况，许多开源开发人员将上门寻找新工作，让他们在您意识到刚刚发生的事情之前就可以从事上游项目。 -### Schedule/Timing Considerations +因此，创建和维护上游工作和产品工作的分离很重要。换句话说，建议为您的开源开发人员提供有保证的时间来满足他们的上游愿望和责任，特别是如果他们是维护人员。对于在产品组件中使用开源的初级开发人员或其他内部开发人员，与上游社区的这种互动将增加他们的语言、沟通和技术技能。 -Providing adequate time in project schedules for upstream contributions is essential. If you have internal developers who are making upstream contributions, you'll need to budget time in their schedules to allow for these contributions to be made. If you are hiring external open source developers into your organization to work upstream, and also work on your product, you'll need to consider how to balance their schedules as well. +在没有这样的上游时间保证的情况下，这些团队成员很容易被吸进成为产品团队的延伸，导致他们的上游重点枯竭而转向产品开发，这在短期内可能会有所帮助，但可以最终会导致您的组织在上游社区中的声誉受损，这会对您在对您的组织有益的领域帮助指导上游项目的能力产生负面影响。 -The core principle for hiring open source developers is to support your open source development and upstream activities. There is also the expectation that they should support product teams in their expertise areas. However, it's not uncommon 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 a new job that allows them to work on their upstream project before you realize what just happened. +### 3.3.7 培训注意事项 -Therefore, it's important to create and maintain a separation of upstream work and product work. In other words, it's recommended to provide your open source developers with guaranteed time to meet their upstream aspirations and responsibilities, especially if they are a maintainer. For junior developers or other internal developers who are 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's easy for these team members to be sucked into becoming an extension of product teams, resulting in their upstream focus drying up in favor of product development, which may help in the short term, but can ultimately lead to loss of your organization's reputation in the upstream community, which can negatively affect your ability to help guide the upstream project in areas beneficial to your organization. +您应该考虑哪些类型的培训？ -### Training Considerations +- 做出上游贡献的最佳实践 +- 关于开源、许可证、治理等的一般培训。 +- 解决冲突或应对具有挑战性的人的培训 -Even if you hire the best outside open source developers, you'll need to consider providing training opportunities for your existing engineering staff, as working with upstream communities can be a very different experience than they may have been used to in the past. +为了随着时间的推移扩大你的努力，在你的培训计划中包括一些编程，这些编程提供经验丰富的开源贡献者作为新贡献者的导师。指导是在与您的产品相关的特定技术领域培养开源人才的有效方式。 -What are some of the kinds of training you should be considering? +从公司外部聘请一些资源很容易，但这种方法有几个限制。另一种方法是通过技术领域和开源方法的培训，将您现有的开发人员转变为开源贡献者。然后，这些开发人员可以与导师配对，以进一步扩展他们的技能。 -- Best practices for making upstream contributions -- General training on open source, licenses, governance, etc. -- Training on conflict resolution or dealing with challenging people +建立一个导师计划，让经验丰富的资深开源开发人员为初级、经验不足的开发人员提供指导。通常，导师计划会持续 3 到 6 个月；在此期间，导师应监督受训者的工作，分配任务，并确保得到适当的结果。导师还会对受指导者产生的任何东西进行代码审查，并在受指导者将代码推送到上游项目之前提供反馈。 -To scale your efforts over time, include in your training plan some programming that provides experienced open source contributors as mentors for new contributors. Mentoring is a powerful way to grow open source talent in specific technology areas relevant to your products. +目标是增加公司为上游项目贡献代码的开发人员数量，并通过提高代码质量和上游项目接受代码的百分比来提高个人效率。一般来说，给定导师分配的学员不应超过 4-5 人，理想情况下，他们应该与导师在同一领域工作，以提高代码审查效率。 -It's easy to hire a few resources from outside the company, but there are several limitations to this approach. The alternative approach is to convert your existing developers into open source contributors via training on the technical domain and open source methodology. These developers can then be paired with a mentor to further expand their skills. +### 3.3.8 工具注意事项 -Set up a mentorship program where senior, experienced open source developers provide mentorship to junior, less experienced developers. Typically, the mentorship program would run for 3 to 6 months; during this time, the mentor should supervise the work of the mentee, assign tasks, and ensure proper results. The mentor would also do code reviews for anything the mentee produces, and provide feedback before the mentee pushes the code to the upstream project. +提供灵活的 IT 基础架构非常重要，它允许开发人员在没有任何挑战的情况下与开源社区进行交流和工作。此外，您应该考虑建立与上游社区外部使用的工具相匹配的内部 IT 基础设施。这有助于弥合内部团队和上游项目社区之间的差距。 -The goal is to increase the number of developers the company has contributing code to the upstream project, and to improve individual effectiveness by increasing the quality of code and the percentage of code that is accepted into the upstream project. Generally speaking, no more than 4-5 mentees should be assigned to a given mentor, and ideally they should work in the same area as the mentor to make code reviews more efficient. +大部分基础设施会自然而然地随着您组织的开源文化而发展，但重要的是要意识到其实施的必要性和计划。开源开发中使用了三个主要的 IT 服务领域： -### Tooling Considerations +- 知识共享（维基、协作编辑平台和公共网站） +- 沟通和解决问题（邮件列表、论坛和实时聊天） +- 代码开发和分发（代码存储库和错误跟踪） -It's important to provide a flexible IT infrastructure that allows developers to communicate and work with the open source community without any challenges. Additionally, you should consider setting up internal IT infrastructure that matches the tools used externally by upstream communities. This helps to help bridge the gap between internal teams and the upstream project community. +这些工具中的部分或全部需要在内部提供，以正确支持开源开发。这有可能与现有的全公司 IT 政策相冲突。如果是这样，解决这些冲突并允许开源开发人员使用他们熟悉的工具至关重要。这些开源实践通常需要一个不受许多标准限制的 IT 基础架构。 -Much of this infrastructure will naturally evolve with your organization's open source culture, but it's important to be aware of the necessity and plan for its implementation. There are three primary domains of IT services that are used in open source development: +### 3.3.9 其他形式的贡献 -- Knowledge sharing (wikis, collaborative editing platforms, and public websites) -- Communication and problem solving (mailing lists, forums, and real-time chat) -- Code development and distribution (code repositories and bug tracking) +请记住，上游社区还需要其他类型的可能与代码无关的支持。查看您感兴趣的项目的治理模型，以确定是否可以选择公司会员或赞助项目或负责该项目的基金会。这提供资金以帮助项目取得成功，并且在某些情况下，它可以帮助您的组织更多地参与咨询角色或对项目产生一些影响。 -Some or all of these tools will need to be made available internally to properly support open source development. There is a chance this might conflict with existing company-wide IT policies. If so, it's vital to resolve these conflicts and allow open source developers to use the tools they are familiar with. These open source practices typically require an IT infrastructure that is free from many standard, limiting IT policies. +除了直接资助项目外，还可以考虑赞助相关会议。这些对于宣传您的工作和结识您可能想招聘的人来说非常有用。特别是，不要忽视您在有员工的本地用户组中的参与。赞助那些当地团体并派遣贡献者进行演讲是招募对特定开源项目充满热情的当地人的好方法。 -### Other Forms of Contribution +### 3.3.10 评估您的上游工作 -Remember that upstream communities also need other kinds of support that may not be code related. Look at the governance models for the projects you're interested in to determine whether there is an option for corporate membership or sponsorship for the project or the foundation responsible for it. This provides funding to help the project be successful, and in some cases, it can help your organization get more involved in an advisory role or provide some influence into the project. +由于您在时间、人员和金钱方面进行了大量投资，因此考虑如何评估您的上游工作非常重要。您可以按照与任何会计投资一样的标准方式跟踪非代码贡献，例如赞助资金，但您应该认真考虑跟踪您关心的项目的贡献。 -In addition to funding projects directly, consider sponsoring related conferences. These can be great for getting the word out about your work and for meeting people who you might want to recruit. In particular, don't overlook your participation in local user groups where you have employees. Sponsoring those local groups and sending contributors to give talks can be a great way to recruit local people who are passionate about particular open source projects. +贡献可以包括上游代码开发、支持产品团队、知识转移（指导、培训）和可见性（出版物、演讲）。 -### Evaluating your Upstream Efforts +有几个工具包可以帮助跟踪源代码贡献；例如，Linux 基金会使用名为 gitdm 的工具，该工具生成 Linux 基金会年度 Linux 内核报告中报告的数据。这可用于跟踪个人开发人员以及团队的整体绩效。可以跟踪个别开发人员提交的补丁数量、补丁接受率（提交的补丁除以接受的补丁）和补丁类型（例如，如果它是新功能、现有功能的增强、错误修复、文档、等）。 -Because you are making a significant investment in time, people and money, it's important to consider how you are going to evaluate your upstream efforts. You can track non-code contributions like sponsorship dollars in the standard way you would any accounting investment, but you should give considerable thought to tracking contributions for projects you care about. +GrimoireLab 等其他工具也可用于绘制和可视化您要跟踪的指标。有关您应该跟踪的具体示例，请参阅有关指标的下一部分。 -Contributions can include upstream code development, supporting product teams, knowledge transfer (mentoring, training), and visibility (publications, talks). +## 3.4 跟踪进度的指标 -There are several toolkits that help track source code contributions; for instance, The Linux Foundation uses a tool called gitdm, which produces the data reported in the Linux Foundation yearly Linux Kernel report. This can be used to track both individual developers as well as the overall team performance. Individual developers can be tracked for the number of patches they submit, the patch acceptance rate (patches submitted divided by patches accepted), and the type of patch (e.g. if it is a new feature, enhancement of existing functionality, bug fix, documentation, etc.). +一旦您开始实施这些开源最佳实践，您将需要适当的开源指标来推动所需的开发行为。 但是产品组织中经常使用的传统指标不适用于开源开发环境。 -Other tools like [GrimoireLab](http://grimoirelab.github.io/) can also be used to chart and visualize the metrics you want to track. See the next section on metrics for specific examples of what you should track. +例如，跟踪变更集或代码行的数量可能是衡量开源开发影响的一个很好的指标。 但是您可能有多个所需功能的实例在上游实现，因为您的开源开发人员游说社区的支持。 在这种情况下，变更集或代码行的数量几乎没有团队成员提供的技术领导力以获取上游代码并减少公司下游维护工作的重要性。 因此，您跟踪的指标应考虑到这两项活动。 -## Metrics for Tracking Progress +### 3.4.1 随着时间推移的提交和行代码 -Once you start implementing these open source best practices, you'll need proper open source metrics to drive the desired development behavior. But the traditional metrics often used in product organizations don't apply in the context of open source development. +要跟踪的最基本的事情之一是在特定时间段(如每周、每月或每年)中提交的数量和代码更改行数。 -For example, tracking the number of changesets or lines of code can be a good metric for open source development impact. But you may have multiple instances of desired functionality being implemented upstream because your open source developers lobby for support from the community. In this case, the number of changesets or lines of code doesn't matter nearly as much as the technical leadership that team members provide to get code upstream and reduce the company's downstream maintenance efforts. So the metrics you track should account for both activities. +![Image description](commits-over-time.png) -### Commits and lines of code over time +### 3.4.2 每周每个项目的总提交和更改行数是开始跟踪指标的好地方。 -One of the most basic things to track is the number of commits and lines of code changed over a specific period of time, such as every week, month, or year. +图1：使用此数据，您可以比较各个内部开发团队的贡献，以确定源代码贡献的来源，并帮助确保资源得到适当分配。 -![Commits and lines of code over time](commits-over-time.png) +从这里您可以创建图表，比较各个内部团队的累积贡献、总贡献的百分比以及将代码提交到上游所需的时间（请参阅以下图表）。 -### The total commits and lines changed per project per week is a good place to start tracking metrics. +![Image description](cumulative.png) -With this data, you can compare contributions from various internal development teams to identify where source code contributions are coming from and help ensure that resources are allocated appropriately. +图2：可以跟踪一段时间内的累积贡献，以比较内部团队并确定增加他们在特定开源社区（在此图表中，是 Linux 内核）中的参与度的团队。 -From here you can create charts that compare various internal teams for their cumulative contributions, percent of total contributions, and the amount of time it takes to get code committed upstream (see the following charts). +![Image description](percent-over-time.png) -![Cumulative contributions over time](cumulative.png) +图3：将您公司的贡献显示为一段时间内总贡献的百分比，可以让您确定贡献最多代码的团队。 -**Figure 2:** Cumulative contributions over time can be tracked to compare internal teams and identify teams that are increasing their involvement in a particular open source community (in this chart, it's the Linux kernel). +![Image description](time-to-commit.png) -![contributions as a percent of total over time](percent-over-time.png) +图4：向上游提交代码所需的时间对于跟踪您的开发效率很有价值。 此表格和图表显示了各个团队向上游贡献代码的速度，并将其与整个社区进行比较。 -**Figure 3:** Displaying your company's contributions as a percent of total over time allows you to identify the teams that contribute the most code. +例如，您还可以使用这些指标将您的业绩与参与内核生态系统的其他公司进行比较（图 5）。 这种竞争分析可帮助您更好地了解项目的整体开发人员生态系统。 -![Time to Commit](time-to-commit.png) +![Image description](cumulative-by-company.png) -**Figure 4:** The amount of time it takes to commit code upstream can be valuable for tracking your development efficiency. This table and chart shows how quickly various teams are getting their code contributed upstream and compares it to the community as a whole. +图 5：可以按公司对累积贡献进行排序，以查看您的公司与其他公司的对比情况。 -You can also use these metrics to compare your performance to other companies who are involved in the Kernel ecosystem for instance (Figure 5). This competitive analysis helps you be better informed about the overall developer ecosystem for the project. +这些指标可以更好地了解您的优势和劣势，并有助于告知您的整体发展战略。 例如，跟踪您自己相对于竞争对手的贡献，可以提供有价值的信息，帮助组织将其产品相对于竞争对手的产品在市场上定位。 -![Cumulative Contributions by Company](cumulative-by-company.png) +成为最高贡献者本身并不是目标，而是表明组织的发展努力正在被其参与的社区所接受。 -**Figure 5:** Cumulative contributions can be sorted by company to see how your company stacks up against others. +### 3.4.3 要记住的事情 -These metrics provide a much better idea of where your strengths and weaknesses are and can help inform your overall development strategy. Tracking your own contributions relative to competitors', for example, provides valuable information that helps an organization position its products relative to competitors' in the marketplace. +到目前为止，我们已经提供了很多关于最有效地与上游开源项目合作的信息。我们将尝试将其提炼为要记住的一些关键事项： -Being a top contributor isn't a goal, in and of itself, but rather an indication that the organization's development efforts are being accepted by the communities in which it participates. +- 建立政策和流程来指导开源贡献 +- 建立一个团队来监督所有开源贡献的批准 +- 专注于能够支持您的技术的领域的贡献 +- 为贡献者提供所需的 IT 基础架构和工具 +- 为您的员工提供有关捐款最佳实践的培训 +- 跟踪贡献、衡量影响、改进和沟通 +- 建立导师计划以培训经验不足的开发人员 +- 提供贡献指南、操作方法、该做什么和不该做什么 +- 为开发人员提供开源法律支持 +- 从您最看重的开源社区招聘 +- 始终遵循特定于每个项目的社区流程和实践 +- 始终考虑您的上游内容是否对整个社区有价值，而不仅仅是针对您的产品的特定案例 -### Things to Remember +# 4. 上游开发实践 -We've presented a lot of information so far about working most effectively with upstream open source projects. We'll try to distill this down to some key things to remember: +## 4.1 课程简介 -1. Establish a policy and process to guide open source contributions -2. Set up a team to oversee approvals for all open source contributions -3. Focus contributions in the areas that will enable your technologies -4. Provide the needed IT infrastructure and tooling for contributors -5. Offer training to your staff on contribution best practices -6. Track contributions, measure impact, improve, and communicate -7. Establish a mentorship program to train less experienced developers -8. Provide contribution guidelines, how-to's, do's and don'ts -9. Make open source legal support accessible to developers -10. Hire from the open source communities you value the most -11. Always follow the community processes and practices specific to each project -12. Always consider if what you're upstreaming is valuable to the whole community, and isn't a specific case just for your product +在本节中，我们将更详细地研究大多数上游项目使用的开发流程和实践，以帮助您提供有关如何实施我们在上一节中讨论的贡献策略的实用指南。 -# Section: Upstream Development Practices +## 4.2 学习目标 -## Lesson: Introduction +在本节结束时，您应该能够： -### Section Overview +- 描述如何做出上游贡献的整体流程 +- 解释如何最好地调整内部流程以实现更好的上游协作 -In this section, we will look in more detail at the development processes and practices used by most upstream projects, to help give you practical guidelines on how to implement the contribution strategies we discussed in the previous section. +## 4.3 流程概览 -### Learning Objectives +### 4.3.1 开始之前 -By the end of this section, you should be able to: +在确定了需要参与的项目之后，花一点时间了解项目的内部运作（包括前面提到的治理）会很有帮助。 以下是一些开始的方法： -- Describe the overall process for how to make upstream contributions -- Explain how to best align internal processes for better upstream collaboration +- 关注项目讨论（邮件列表、IRC、Slack、论坛）以了解正在进行的工作 + - 谁是核心开发者？ + - 什么是高度优先的领域？ + - 发布周期如何运作？ + - 目前未解决的主要错误有哪些 +- 试用最新的稳定版和实验版 +- 确定您的兴趣和优先事项如何与项目的兴趣和优先事项保持一致 +- 在社区中寻找与您有共同兴趣和优先事项的其他人，并与他们一起工作 -## Lesson: Process Overview +### 4.3.2 信号意图 -### Before You Begin +![Image description](signal-intent.png) -After you've identified the projects you'll need to contribute to, spending a little time understanding the project's inner workings (including governance, as mentioned previously) will be helpful. Here are some ways to begin: +与社区沟通您计划提交哪些更改非常重要。 该过程通常从通过社区使用的任何机制向社区发送消息开始。 -- Follow the project discussions (mailing lists, IRC, Slack, discussion forums) to understand ongoing efforts - - Who are the core developers? - - What are areas of high priority? - - How do release cycles work? - - What are the major bugs currently outstanding -- Experiment with latest stable and experimental releases -- Determine how your interests and priorities align with those of the project -- Find others in the community who share your interests and priorities, and work with them +这种公开讨论是一个先决条件，有助于让维护者意识到你正在努力解决的需求和问题。 它通常可以帮助您招募其他人来帮助完成工作，并让您在进行大量工作（并拒绝您的更改）之前收集有关有用性和设计考虑因素的反馈。 -### Signal Intent +当您提出更改建议时，请记住以下重要事项： -![Signal Intent](signal-intent.png) +- 它应该对其他人有用，而不仅仅是对您的特定使用模型 +- 它应该以小部分实施，并以提供立竿见影的方式交付 +- 它应该得到准备在组织内实施和维护它的资源的支持 -It's important to communicate with the community about what changes you are planning to submit. The process typically starts with sending a message to the community through whatever mechanism they are using. +### 4.3.3 讨论和理由 -This public discussion is a prerequisite and helps make maintainers aware of the need and the problems you are working to solve. It can often help you recruit others to help do the work, as well as let you gather feedback on the usefulness and design considerations before doing a lot of work (and having your change rejected). +![Image description](discussion.png) -As you propose your change, keep these important things in mind: +提交变更请求后，通常会在社区用于主要沟通的任何工具中进行某种形式的讨论。 这时候，它给了其他感兴趣的人一个评论、提供反馈、批评的机会，也给了维护者一个评论项目是否准备好接受这样的变化的机会。 -- It should be useful to others and not just to your specific usage models -- It should be implemented in small parts, and delivered in a way that provides immediate benefit -- It should be backed by resources ready to implement and maintain it within your organization +此阶段的意见可以从简短的批准到有关实施的详细问题，特别是如果更改被认为是高风险的或可能侵入项目的核心部分。 最好先考虑一下如何说服他人并解决您在第一次发送此通信时可能遇到的潜在挑战。 -### Discussion and Rationale +### 4.3.4 接受 -![Discussion and Rationale](discussion.png) +![Image description](acceptance.png) -After a change request has been submitted, there is often some form of discussion in whatever tool the community uses for primary communication. At this time, it gives other interested parties an opportunity to comment, provide feedback, critiques, and it also gives maintainers an opportunity to comment on whether the project is ready to accept such a change. +在社区讨论之后，如果维护者和其他相关方同意，则接受更改，并讨论一些额外的考虑因素，包括确定更改对项目的战略性，表明提议的实施似乎没问题，以及普遍的共识 更改不太可能影响项目的稳定性、安全性或整体功能。 -The comments at this stage could range from brief approval to detailed questions about implementation, especially if the change is considered high-risk or potentially intrusive to core parts of the project. It's a good idea to have some thoughts about how you want to convince others and address potential challenges you may see when you first send this communication. +一个或多个项目维护者通常会在此阶段表示他们的批准。 -### Acceptance +### 4.3.5 跟踪提议的贡献 -![Acceptance](acceptance.png) +![Image description](tracking.png) -After the community discussion, if the maintainers and other interested parties agree, the change is accepted, and some additional considerations are debated, including ascertaining how strategic the change is to the project, an indication that the proposed implementation seems ok, and general consensus that the change is unlikely to affect stability, security, or overall functionality of the project. +一旦更改被接受，就需要对其进行跟踪，这通常以某种形式的功能或错误跟踪发生，具体取决于项目社区使用的工具。 此跟踪条目被认为是提议的内容和被接受的更改内容的权威记录。 -One or more of the project maintainers will usually signal their approval at this phase. +在这个阶段，原始提交开发人员将详细的功能信息添加到跟踪工具中，以便记录更改将影响哪些子系统以及实施的总体计划是什么。 -### Tracking Proposed Contribution +### 4.3.6 优先排序 -![Tracking Proposed Contribution](tracking.png) +![Image description](priortization.png) -Once a change has been accepted, it needs to be tracked, and this usually occurs in some form of feature or bug tracking, depending on what tools are used by the project community. This tracking entry is considered the authoritative record of what was proposed and what was accepted as a change. +变更被接受和跟踪后，需要将其接受与项目的所有其他未决变更一起确定优先级。 在这一点上，维护人员再次参与以优先考虑哪些传入更改是项目的核心，哪些是立即需要的，哪些可以稍后接受。 -At this stage, the original submitting developer adds detailed feature information into the tracking tool so that a record is maintained of what subsystems the change will affect and what the overall plan for implementation is. +由于维护人员通常对依赖项和未来版本有全局看法，因此他们可以努力确定更改的优先级并正确调整功能。 但是，如果更改足够小，或者没有触及项目的太多核心部分，他们可能会在准备就绪后立即表示他们已准备好接受它。 -### Prioritization +### 4.3.7 发布计划 -![Prioritization](priortization.png) +![Image description](release-planning.png) -After a change has been accepted and tracked, its acceptance needs to be prioritized in conjunction with all other pending changes to the project. At this point, maintainers get involved again to prioritize which incoming changes are core to the project, and which are needed right away versus which can be accepted later. +一旦维护人员完成了传入更改的优先级排序，他们将努力与提交更改请求的原始开发人员（以及整个社区）就何时准备好集成更改进行沟通。 这有助于维护者和社区计划每个版本的可管理数量的功能。 -Because maintainers generally have a global view of dependencies and future releases, they can work to prioritize changes and align features correctly. However, if a change is minor enough, or doesn't touch too many core parts of the project, they may signal they are ready to accept it as soon as it's ready. +在此阶段，原始提交者将收到有关其更改计划用于哪些特定未来版本的通知。 -### Release Planning +### 4.3.8 开发与质量保证 -![Release Planning](release-planning.png) +![Image description](development-qa.png) -Once a maintainer has completed prioritization of the incoming change, they will work to communicate the original developer who submitted the change request (as well as the entire community) on when they will be ready to integrate the change. This helps the maintainer and community plan for a manageable number of features per release. +在流程中的所有先决条件都完成后，可以进行实际的开发和质量保证，开发人员和从社区招募的任何其他资源介入并开始实施新的更改，针对维护者设置的特定版本 . -During this phase, the original submitter will get notification of what specific future release their change is planned for. +如果由于某种原因开发遇到问题，或者看起来他们无法在分配给他们的特定发布窗口中进行，那么尽早与维护者和社区进行沟通很重要，以便对其更改的任何依赖都可以 在即将到来的发布周期中进行调整。 -### Development & QA +## 4.4 调整内部流程 -![Development & QA](development-qa.png) +### 4.4.1 从哪里开始 -After all of the prerequisites in the process are completed, the actual development and Quality Assurance can take place, where the developer and any other resources recruited from the community step in and begin to implement the new change, targeting the specific release set by the maintainer. +当您将变更贡献回上游社区时，考虑如何最好地调整您的内部开发流程以使其更有效，这一点很重要。 虽然您可能仍然拥有独特的内部或闭源软件产品开发流程，但在与上游开源项目合作时能够转换上下文并有效工作对于您的上游贡献以及帮助您最有效地使用开源项目都很重要 项目到您的内部代码。 -If for some reason the development runs into issues or it looks like they won't be able to make the specific release window they were assigned to, it's important for them to communicate early with the maintainer and community so that any dependencies on their change can be adjusted in the upcoming release cycles. +为了让自己设置贡献，你通常遵循下面概述的过程（这个例子来自 Github，但可以推广到任何使用 git 作为源控制系统的系统）： -## Lesson: Aligning Internal Processes +![Image description](setup.png) -### Where to Start +如果这是一个小的开源项目或者你组织中的其他人不太可能使用的项目，你通常可以在 Github 上将 fork 留在你自己的帐户中，但是如果它很可能被你组织中的其他团队使用，你 可能希望将上游项目分叉到公司所有的组织中，以便于维护。 -It's important to consider how to best align your internal development processes to be more effective when you are contributing changes back to an upstream community. While you may still have unique development processes for internal or closed source software products, being able to shift contexts and work effectively when collaborating with upstream open source projects is important both for your upstream contributions, but also to help you most effectively consume the open source projects into your internal code. +完成初始设置后，通过“拉取请求”向上推送更改的一般工作流程如下所示： -To get yourself setup for a contribution, you generally follow the process outlined below (this example is from Github, but can be generalized to any system utilizing git as the source control system): +![Image description](pull-requests.png) -![Set up to Contribute](setup.png) +### 4.4.2 内部镜像 -If this is a small open source project or one that is unlikely to be used by others in your organization, you can generally leave the fork on Github in your own account, but if it's likely to be used by other teams in your organization, you may want to fork the upstream project into a company-owned organization for easier maintenance. +对于一些组织，特别是那些对Internet上开放源码存储库的长期可用性有潜在担忧的组织，在组织内部增加一个存储库结构层可能是有意义的。例如: -Once you've done the initial setup, the general workflow of pushing changes up through "pull requests" looks like this: +![Image description](internal-mirror.png) -![Pull Requests](pull-requests.png) +此外，对于某些组织而言，拥有开源项目内部镜像的“舒适因素”使他们能够更轻松地对产品中的开源使用进行合法签署。 -### Internal Mirrors +虽然它确实提供了一层安全性，但它也增加了上游更改的工作量，因为您需要将这些更改从本地开发人员存储库推送到内部镜像，然后在提议之前推送到 Github 上的实际分支 你的拉取请求。 -For some organizations, especially those that have potential concerns about the long-term availability of open source repositories on the Internet, it may make sense to have an additional layer of repository structure inside your organization. For example: +### 4.4.3 内部协作 - +无论您选择在有或没有内部镜像的情况下对上游项目进行消费和贡献，您仍然需要在组织内建立沟通和协作实践，以确保： -![Internal Mirror](internal-mirror.png) +- 您正在处理上游项目的一小部分已批准版本 +- 您所做的更改不是多余的或与您的内部团队发生冲突 +- 您对上游项目提出的更改在整个公司内是一致的 -Additionally, for some orgs, the "comfort factor" of having this internal mirror of an open source project gives them the ability to more easily have legal sign-off on usage of open source in products. +### 4.4.4 协调上游拉取请求 -While it does provide a layer of safety, it does also increase the workload for changes going upstream, as you'll need to push those changes from your local developer repo to the internal mirror, and then on to the actual fork on Github before proposing your pull request. +如果您有多个团队使用并可能对上游开源项目进行更改，那么您必须努力协调对该项目所做的任何更改，这一点很重要。无论您是在内部镜像仓库还是公共组织仓库中监控和优先级/澄清这些更改，它都有助于识别组织内部负责充当中间“上游”审查团队的内部“维护者”。 -### Internal Collaboration - -Whether you choose to have your consumption of and contribution to upstream projects happen with or without an internal mirror, you'll still need to build communication and collaborative practices within your organization to make sure that: - -- You're working on a small set of approved versions of the upstream project -- Changes you're making are not redundant or in conflict with your internal teams -- Changes that you're proposing to the upstream project are consistent across the company - -### Coordinating Upstream Pull Requests - -If you have multiple teams consuming and potentially making changes to an upstream open source project, it's important that you work to coordinate any changes that are being made to that project. Whether you monitor and prioritize/clarify those changes in an internal mirror repo, or your public organizational repo, it helps to identify internal "maintainers" inside of your organization that have a responsibility for acting as an intermediate "upstream" review team. - -Effectively coordinating your upstream project contributions in a large engineering organization can seem like a lot of extra work, but it's needed if you want to keep the upstream project effective and healthy so you can rely upon it, and, also so that your organization's reputation with the upstream community remains intact. Having many conflicting changes from a single organization going to the upstream project can have a detrimental effect on how your organization is viewed by the open source community, which negatively affects your ability to work with them long-term. +在大型工程组织中有效地协调您的上游项目贡献似乎是很多额外的工作，但如果您想保持上游项目有效和健康，以便您可以依赖它，并且还需要您的组织在以下方面的声誉上游社区保持完整。从单个组织到上游项目的许多相互冲突的更改可能会对开源社区如何看待您的组织产生不利影响，从而对您与他们长期合作的能力产生负面影响。 diff --git a/sources/OSPO-101/module7/README.md b/sources/OSPO-101/module7/README.md index 725de2d..7588b67 100644 --- a/sources/OSPO-101/module7/README.md +++ b/sources/OSPO-101/module7/README.md @@ -1,420 +1,414 @@ --- -status: collected -title: "OSPO 101 Training Modules - Module 7" +status: translated +title: "OSPO 101 Training Modules - Module 2" author: TODO Group collector: mudongliang collected_date: 20240822 +translated_date: 20241010 +translator: Hao Guo link: https://github.com/todogroup/ospo-career-path/blob/main/OSPO-101/module7/README.md --- +# 1. 介绍 -# Open Source Project Creation Overview +## 1.1 课程简介 -## Lesson: Introduction +在本节中，我们将了解创建新开源项目的基本原理和价值主张。 我们将花时间讨论创建新开源项目的好坏理由，以及如何评估新项目的商业潜力。 -### Section Overview +## 1.2 学习目标 -In this section, we’ll look at the rationale and value proposition for creating new open source projects. We’ll spend time discussing good and bad reasons to create new open source projects, as well as how to evaluate the business potential of a new project. +在本节结束时，您应该能够： -### Learning Objectives +- 描述开源内部代码或从头开始创建新的开源项目的价值主张 +- 给出一些开源代码理由的好坏例子 +- 解释如何评估一个新的开源项目的商业潜力 -By the end of this section, you should be able to: +# 2. 从哪里开始？ -* Describe the value proposition for open sourcing internal code or creating new open source projects from scratch -* Give some good and bad examples of reasons to open source code -* Explain how to evaluate the business potential of a new open source project +## 2.1 提出正确的问题 -## Lesson: Where To Begin? +在开始创建新的开源项目之前提出正确的问题很重要。 虽然根据贵公司的独特情况，您可能还应该考虑一些其他具体问题，但下图将为您提供一个很好的开端，帮助您弄清楚要问什么。 -### Ask The Right Questions +![Image description](questions-to-ask.png) -It’s important to ask the right questions before you begin the journey of creating a new open source project. While there may be some additional specific questions you should consider depending on your company’s unique situation, the following picture will give you a great start to help you figure out what to ask. +此图的第一行真正涉及了解创建开源项目的价值主张是什么的问题。不幸的是，第一个问题并没有被经常问到——你应该认真评估是否需要创建另一个开源项目。存在成千上万个项目——您的代码是否会单独提供差异化​​的价值，还是让一个成熟且成功的开源项目变得更好？ -![Questions to Ask Before Open Sourcing Project](questions-to-ask.png) +如果您的组织了解开源开发模型（在本系列课程的前几节中进行了介绍）并致力于构建具有该结构的项目，那么在决定启动该项目之前，您仍然需要评估成功的要素和衡量标准会用。仅仅为了公共关系的目的而创建一个项目，或者为了改进开源项目启动数量的内部指标，通常会导致一个不成功的项目。 -The top line of this graphic really deals with the question of understanding what the value proposition is for you to create an open source project. The first question is one that, unfortunately, doesn’t get asked often enough - you should seriously evaluate whether or not you need to create another open source project. There are many thousands of projects in existence - will your code provide differentiated value on its own, or would you be better off making an established and successful open source project even better? +第二排问题更侧重于您的组织和社区在新的开源项目中创造价值的能力。太多的公司已经尝试（但失败）的策略是简单地将代码扔过防火墙，没有内部财务和工程投资，并希望他们的企业声誉能够吸引外部企业的参与。 -If your organization understands the open source development model (covered in previous sections of this course series) and is committed to building a project with that structure, you’ll still need to evaluate **before** deciding to launch the project what constitutes success and what metrics you’ll use. Just creating a project for the purposes of public relations or to improve internal metrics for the number of open source projects started will usually result in an unsuccessful project. +花点时间考虑如何让您的潜在新开源项目取得成功。如果您得出的结论是创建开源项目不适合特定代码段，那也没关系——有很多机会参与开源生态系统或将您的技术贡献给其他开源项目。 -The second row of questions focuses more on the ability of your organization and the community to build value in the new open source project. Too many companies have tried (and failed) with the strategy of simply throwing code over their firewall, without internal financial and engineering investment, and hoping that their corporate reputation will attract outside enterprise participation. +## 2.2 你应该开源什么？ -Take the time to consider how to make your potential new open source project successful. It’s ok if you come to the conclusion that creating an open source project isn’t right for a particular piece of code - there are many opportunities to participate in the open source ecosystem or contribute your technology to other open source projects. +正如您必须决定向上游开源社区贡献什么（来自本系列之前的课程），决定您最初将在开放中构建什么代码或技术，或者您的专有代码。我发布是一个重要的。以下是一些可以帮助您考虑此选择的标准。 -### What Should You Open Source? +- 确定您的产品的哪些部分是战略优势的来源，以及什么只是支持这些部分 +- 非战略部分通常是创建开源项目的理想选择 + - 其他公司很有可能也有同样的感觉，并且可能会帮助您维护和推进新项目。 -Just as in the decision you must make on what to contribute back to an upstream open source community (from previous coursework in this series), the decision on what code or technology you’ll build initially in the open, or what proprietary code you’ll release is an important one. Here are some criteria that can help you consider this choice. +例子： -* Determine what parts of your product are sources of strategic advantage, and what simply supports those parts -* Non-strategic parts are often great candidates for creating open source projects - * Chances are good that other companies feel the same way, and might help you maintain and advance your new project. +- 行业中广泛使用的文件系统或文件格式 +- 连接物联网设备的网络堆栈 -Examples: +另一个起点包括二次编码项目，在这种项目中，企业不需要成为权威，并且可能有更多的世界各地的技术人员可以帮助您解决问题。如果它不是关键任务代码，那么它很可能是开源的一个很好的候选者。但是，它也应该是贵公司仍在积极使用和维护的代码。对代码的商业依赖使错误修复、补丁和新功能的持续反馈循环成为可能。 -* A filesystem or file format widely used in the industry -* The network stack for connected IoT devices +## 2.3 何时创建开源项目 -Another place to start includes secondary coding projects where an enterprise does not need to be an authority, and where there may be a larger group of technologists around the world who can help you solve a problem. If it is not mission-critical code, then it is likely a good candidate to be open sourced. However, it should also be code that your company is still actively using and maintaining. Commercial dependencies on code enable a continuous feedback loop of bug fixes, patches and new features. +发布或创建新的开源项目的决定取决于您的情况。 您的公司应该首先通过使用开源软件并为现有项目做出贡献来达到一定程度的开源掌握（正如我们在本系列之前的课程中介绍的那样）。 +了解如何使用开源可以教会您如何利用外部项目和开发人员来构建您的产品。 参与可以使开源社区的惯例和文化更加流畅。 但是，一旦您实现了开源流畅性，开始启动自己的开源项目的最佳时机就是“早”和“经常”。 -### When To Create an Open Source Project +![Image description](release-early.png) -The decision to release or create a new open source project depends on your circumstances. Your company should first achieve a certain level of open source mastery by using open source software and contributing to existing projects (as we covered in previous coursework in this series). +此图提醒我们在本课程系列的开源开发实践部分中涵盖的内容。 这不仅在您回馈开源时很重要，在您考虑第一个新的开源项目时也很重要。 -Understanding how to consume open source can teach you how to leverage external projects and developers to build your products. Participation can bring more fluency in the conventions and culture of open source communities. But once you have achieved open source fluency, the best time to start launching your own open source projects is simply “early” and “often.” +在您创建第一个开源项目之前，并非一切都必须绝对完美。 在流程、法律审查等方面有一些最低要求（我们将很快介绍），但在代码和治理方面建立最低要求以开始使用可以让您获得更早的参与和更早的反馈，以帮助您发展 你的新项目。 -![Release Early Release Often](release-early.png) +不过，在您创建第一个项目之前，我们应该讨论创建开源项目的一些好的（和坏的）原因...... -This graphic is a bit of a reminder about what we covered in the _Open Source Development Practices_ portion of this coursework series. It’s not only important when you’re contributing back to open source, it’s important as you consider your first new open source projects. +## 2.4 创建开源项目的好理由 -Not everything has to be absolutely perfect before you create your first open source project. There are some minimums in terms of process, legal review, etc. (which we’ll cover shortly), but building out the minimum necessary in both code and governance to get started allows you to get earlier participation and earlier feedback to help you evolve your new project. +![Image description](good-reasons-to-opensource.png) -Before you create that first project though, we should discuss some good (and bad) reasons for creating an open source project... +此图显示了您应该启动开源项目的五个充分理由。 虽然他们都回到业务目标，但前两个涉及在市场上获得独特的业务优势。 然而，重要的是要注意，这种“先行者”的业务优势可能是短暂的（6-10 个月），直到社区的其他人精通您开源的技术。 -### Good Reasons to Create an Open Source Project +第三和第四项侧重于吸引客户并帮助您的非开源产品创造价值。 请记住，在开源代码中，您在提供价值的基础上，使您的产品变得更好。 -![Good Reasons to Create an Open Source Projects](good-reasons-to-opensource.png) +最后，如果你所在的行业有技术客户（或开发人员），他们有能力用你的技术自给自足，你可以意识到不必为你选择开源的代码提供额外的技术或支持资源的价值。 -This graphic shows five good reasons why you should start an open source project. While they all come back to business goals, the first two deal with getting a unique business advantage in the market. It’s important to note, however, that this ‘first-mover’ business advantage can be fleeting (6-10 months) until the rest of the community becomes proficient with the technology you’ve open sourced. +## 2.5 创建开源项目的错误理由 -The third and fourth items focus on engaging customers and helping build value for your non open-source products. Remember that in open sourcing code you provide value on top of, you’re making your products better as a result. +与出于正确的原因开源一样重要的是确保您不会出于错误的原因尝试创建开源项目。 开源生态系统充斥着来自组织的失败项目，这些项目本意很好，但根本没有充分考虑为什么他们应该开源代码或创建一个新项目。 -Finally, if you are in an industry with technical customers (or developers) who have the ability to self-support themselves with your technology, you can realize value in not having to provide extra technical or support resources for the code you choose to open source. +![Image description](bad-reasons-to-create-opensource.png) -### Bad Reasons to Create an Open Source Project +以下是一些创建新开源项目的不良理由示例： -Just as important as open sourcing for the right reasons is making sure you don’t try to create an open source project for the **wrong** reasons. The open source ecosystem is littered with failed projects from organizations that meant well, but simply didn’t consider fully why they should be open sourcing code or creating a new project. +- 摆脱过时的软件 +- 当你不愿意投资时，期待开源社区的免费工程 +- 作为终止生命公告的积极营销手段 +- 在无意长期支持项目的情况下获得宣传或营销推广 +- 作为实现内部成功指标的一种手段 -![Bad Reasons to Create Open Source Projects](bad-reasons-to-create-opensource.png) +希望很明显为什么所有这些都是创建开源项目的糟糕理由，但让我们看看它们都有什么共同点 - 内部关注和/或对更大开源社区的支持的期望。 -Here’s some examples of bad reasons to create a new open source project: +在开源中工作经常被描述为（从企业的角度）“开明的利己主义”。在这种情况下这是恰当的，因为每个人都明白企业不一定出于利他的原因使用开源 - 必须有商业价值与开源中发生的事情保持一致。然而，上面显示的原因播下了对开源社区其他人不信任的种子，毕竟开源社区是由合作伙伴和竞争对手组成的。 -* Getting rid of obsolete software -* Expecting free engineering from the open source community when you aren’t willing to invest -* As a positive marketing spin on an end-of-life announcement -* To gain publicity or marketing outreach without the intention to support the project long term -* As a means of fulfilling internal success metrics +## 2.6 评估开源项目的商业潜力 -Hopefully it’s obvious why all of these are bad reasons to create an open source project, but let’s look at what they all have in common - an inward focus and/or expectation of support from the larger open source community. +就像任何业务决策一样，确定应该创建什么、是否以及何时创建开源项目会回到最终交付给业务的价值。在考虑这些问题时，最好从构建业务案例的角度进行思考。 -Working in open source has often been described (from the corporate point of view) as ‘enlightened self-interest.’ It’s apropos in this case because everyone understands that corporations don’t work with open source necessarily for altruistic reasons - there has to be business value aligned with what goes on in open source. However, the reasons shown above sow a seed of mistrust with the rest of the open source community, which is, after all, composed of both partners and competitors. +首先，您必须决定您的公司是要在保持代码和项目所有权的同时创建或发布代码，还是要将代码捐赠给其他人来维护和管理项目。如果代码已经存在，则存在相关问题，即您是将项目中的所有代码发布还是仅将其中的一部分作为开​​源项目发布。 -### Evaluating the Business Potential of an Open Source Project +要做出这些决定，请考虑退后一步来确定您为代码设定的目标。这段代码是否对您的组织之外有用并且对行业也有变革意义？贵公司是否有可能吸引合作伙伴（和/或竞争对手）使用这项技术来支持贵组织的产品组合？ -Just like any business decision, determining what, if, and when you should create an open source project comes back to what value is ultimately delivered to the business. As you consider these questions, it’s best to think in terms of building a business case. +例如，您可能希望从其他开发人员那里获得关于应用程序中非您工作核心部分的新见解。或者，您可能会寻求其他实际算法来检测系统监控应用程序中的日志。您可以只发布与算法相关的代码，而不是将整个产品作为开源发布。这使您能够获得他人的贡献并帮助需要类似帮助的其他人，而不会影响您的核心业务。 -First, you must decide if your company wants to create or release the code while maintaining ownership of it and the project, or if you want to donate the code to others to maintain and administer the project. If the code already exists, then there is the related issue of whether you will release all the code in a project or just some of it as an open source project. +启动一个项目并保持总体控制可以让您进行监督，并让您能够帮助将其塑造成您需要的东西，同时仍然为贡献的开发人员提供自由和控制来完成他们的工作。 -To make these decisions, consider stepping back to determine the objectives you have in mind for the code. Is this code something that will be useful outside of your organization and also transformative to the industry? Is your company likely to attract partners (and/or competitors) to work on this technology in support of your organization’s product portfolio? +# 3. 新项目准备 -For example, you might want to attract fresh insights from other developers on a part of an application that isn’t core to your work. Or you might seek additional real-life algorithms to detect logs in a system monitoring application. Rather than releasing the whole product as open source, you could release only the code related to the algorithms. This allows you to gain the contributions of others and help others who are needing similar help, without compromising your core business. +## 3.1 简介 -Starting a project and maintaining overall control lets you have oversight and gives you the ability to help shape it into what you need, while still giving freedom and control to the contributing developers to do their work. +在本节中，我们将探讨如何为创建新的开源项目做准备，包括讨论法律、商业和社区考虑因素。 我们还将讨论成功所需的流程、工具和人员配备要求。 -# Section: New Project Preparations +## 3.2 学习目标 -## Lesson: Introduction +在本节结束时，您应该能够： -### Section Overview +- 解释准备创建一个新的开源项目的总体步骤 +- 了解项目创建成功需要哪些流程、注意事项、工具和要求 -In this section, we will explore how to prepare for creating a new open source project, including discussion of legal, business and community considerations. We’ll also discuss required processes, tools and staffing requirements necessary for success. +## 3.3 内部准备 -### Learning Objectives +### 3.3.1 确定执行保荐人 -By the end of this section, you should be able to: -* Explain the overall steps for preparing to create a new open source project -* Understand what processes, considerations, tools and requirements are needed for success in project creation +由于创建成功的开源项目需要大量投资，因此获得组织中执行发起人的支持至关重要。 如果您有多个赞助商，这会有所帮助，但至少，您应该瞄准能够提供并承诺以下事项的人： -### Lesson: Internal Preparations +#### 3.3.1.1 技术和社区 -### Identify an Executive Sponsor +- 继续公开重申对项目的承诺 +- 培养以绩效为基础的认可文化 +- 确保中立 +- 承诺遵循开源方法和流程 -Since there will be a lot of required investment to create a successful open source project, it’s **critical** to get the buy in of an executive sponsor in your organization. It can help if you have more than one sponsor, but at a minimum, you should aim for someone who can provide and commit to the following things: +#### 3.3.1.2 财务 -#### Technical and Community +内部：提供足够的开发资金以启动项目 +外部：致力于为 IT 资源和系统管理员提供资金 -* Continually reaffirm commitment to the project in public -* Foster a culture of merit-based recognition -* Ensure neutrality -* Commit to following open source methods and processes +### 3.3.2 分配资源 -#### Financial +您需要让您的执行发起人适当分配资金，如上一页所述，但也需要能够安排适当的员工时间来使项目取得成功。最初开发人员的时间可能与他们花在内部代码工作上的时间相似。但是，您还需要考虑您的开发人员需要提供哪些时间、材料或帮助，以帮助新社区中的其他人快速了解代码库。 -* Internally: Fund enough development to get project going -* Externally: Commit to funding IT resources and sysadmins +法律团队也需要资源，参与创建一个可能涉及竞争对手的开源项目，以及营销投资，以确保项目在启动后获得支持和贡献者。 -### Allocate Resources +您还必须为用于开始和维护项目的基础设施设置预算。这包括项目托管和源代码控制网站，如 GitHub，代码将在其中驻留和维护，以及错误解决方案和其他所需的工具。 -You’ll need to get your executive sponsor to appropriately allocate funds, as noted in the previous page, but also be able to direct appropriate staff time to make the project successful. Developer time will likely be similar initially to the amount of time they spend on internal code efforts. However, you’ll also need to consider what time, materials or help your developers will need to provide to help others in the new community get up to speed on the codebase. +我们很快就会更详细地介绍工具和基础设施。 -There will also be resources needed for the legal team that will be involved in creating an open source project that could involve competitors, as well as marketing investments to ensure that the project gains support and contributors after launch. +### 3.3.3 培训您的员工 -You’ll also have to set budgets for the infrastructure used to begin and maintain the project. This includes a project hosting and source control website like GitHub, where the code will reside and be maintained, as well as bug resolution, and other needed tools. +即使您的组织已经接受了开源主题的培训（例如本系列课程），提醒工程团队和经理注意可能与他们通常的构建产品或评估工作的方式不同的特定项目也很重要。 -We’ll cover tools and infrastructure in more detail shortly. + **对于工程师** -### Educate Your Workforce +- 回顾开源开发方法和流程 +- 查看贵公司的开源政策和合规性规则 +- 在您的软件开发模型中集成开源软件 +- 如果可能，在内部遵循开源最佳实践 +- 实践并鼓励社区思考，以帮助制定更通用的解决方案 -Even if your organization has taken training on open source topics (such as this course series), it’s important to remind engineering teams and managers of particular items that may differ from how they normally approach building products or evaluating work. + **对于经理** -#### For Engineers +- 传统的绩效指标可能不再适用 + - 只计算结果，不计算使用谁的代码 + - 影响结果与编写代码一样有效 +- 管理你的开发者，而不是他们的维护者 + - 你无法控制开源进程 +- 您的员工和社区都有学习曲线 +- 建立影响力和尊重需要时间（即使这是您公司的项目） -* Review open source development methods and processes -* Review your company's open source policies and compliance rules -* Integrate open source software within your software development model -* Follow open source best practices internally if possible -* Practice and encourage community thinking to help craft more general solutions +## 3.4 审查 -#### For Managers +### 3.4.1 概述 -* Traditional performance metrics may no longer apply - * Only results count, not whose code is used - * Influencing an outcome is just as valid a solution as writing code -* Manage your developers, not their maintainers - * You can’t control the open source process -* There is a learning curve for your employees and the community -* Building influence and respect takes time (even if it’s your company’s project) +虽然有些受众在启动新的开源项目等工作之前不一定喜欢冗长的评论，但重要的是要花一些时间来正确规划法律团队、工程团队和营销团队的评论。 +这些不一定是痛苦的，因为一组简单的清单来验证最常遗漏的元素不会从裂缝中溜走可能会有所帮助。在创建一个新的开源项目的过程开始时利用这段时间可以在项目完成并获得可见性后省去很多麻烦。 -### Lesson: Reviews +我们将在以下部分介绍如何简化这些审核流程的一些最佳实践。 -### Overview +### 3.4.2 法律审查 -While some audiences don’t necessarily appreciate lengthy reviews before launching efforts such as a new open source project, it’s important to take some time to properly plan for reviews from the legal team, the engineering team and also the marketing team. +新项目可能发生的最糟糕的事情之一是社区对代码库的合法清洁度不信任。确保您发布的代码具有明确的许可和出处非常重要。全面的法律审查通常有助于确保社区中的其他人可以接受所贡献的内容。 -These don’t necessarily have to be painful, as a simple set of checklists to verify that the most often missed elements don’t slip through the cracks can be helpful. Taking this time at the start of the process of creating a new open source project can save a lot of headaches once a project is out and gaining visibility. +您的法律审查还应包括商标尽职调查和注册。请注意，如果您将项目贡献给基金会（稍后将在治理部分详细介绍），请确保在开源代码库之前与商标策略保持一致。 -We’ll cover some best practices in the following sections for how to streamline these review processes. +您还需要为您的项目选择一个许可证。记录任何许可或知识产权要求很重要。项目通常需要同时考虑出站许可（例如，下游用户接收代码所依据的许可）和入站贡献机制（例如，向项目做出贡献的过程）。许多项目将使用开发商的原产地证书 (DCO) 签核流程作为其入站贡献机制。如果您预计需要明确的公司对专利授权的承诺，或以后重新许可项目的能力，您可能需要查看一些更常见的贡献者许可协议（通常称为 CLA）。并非所有 CLA 都相同，因此请仔细考虑此选项。另请注意，CLA 可能会成为参与的障碍，因为开发人员通常必须通过繁琐的审批流程才能签署。有关许可选项的更多详细信息，请参阅本培训系列的开源合规性计划模块。 -### Legal Review +您的项目也可能产生非软件的可交付成果。如果您的项目正在生成文档，请讨论您是否应该为文档使用特定的许可证。例如，许多开源项目将使用软件的开源许可证和文档的知识共享许可证。此外，一些项目寻求创建可由其他人以各种方式实施的规范。这些项目应该考虑使用规范许可证的选项。 -One of the worst things that can happen to a new project is for the community to have distrust in the legal cleanliness of a codebase. It’s important to ensure the code you release has clear licensing and provenance. A full legal review is often helpful in making sure what gets contributed will be acceptable by others in the community. +每种许可方法都有其优点和缺点，但请注意分散项目的可能性，这对于需要互操作或提供跨各种供应商解决方案可移植性的软件来说是一个特殊问题。如果商业解决方案通过社区创建的测试或一组要求，则通常通过创建允许使用项目商标的一致性程序来解决此问题。预先考虑这一点将有助于为您的法律审查和项目计划提供信息。 -Your legal review should also include trademark due diligence and registration. Note that if you are contributing the project into a foundation (more on this later in the governance section), make sure you’re aligned on the trademark strategy before open sourcing your codebase. +总之，法律审查过程的步骤包括： -You’ll also need to choose a license for your project. It’s important to document any licensing or intellectual property requirements. Projects will typically need to consider both the outbound license (e.g., the license under which downstream users receive the code) and the inbound contribution mechanism (e.g., the process under which contributions are made into the project). Many projects will use the [Developer’s Certificate of Origin](https://developercertificate.org/) (DCO) sign-off process for their inbound contribution mechanism. If you anticipate needing explicit corporate commitments for patent grants, or the ability to relicense the project later, you may want to look at some of the more common Contributor License Agreements (commonly referred to as CLAs). Not all CLAs are alike, so consider this option carefully. Also be aware that CLAs can be an impediment to participation as developers often have to go through arduous approval processes to get them signed. Refer to the _Open Source Compliance Program_ module of this training series for more detailed information on licensing options. +- 考虑开源对贵公司知识产权的影响 +- 确保完全符合开源许可证 +- 为要发布的源代码选择一个开源许可，在您的项目中非常清楚地记录所有许可要求 +- 决定您是否需要贡献者协议 +- 考虑来自社区的可能的非软件输出和适当的许可证，例如文档和规范 +- 决定任何与商标相关的考虑因素 +- 确定您的生态系统计划中是否包含其他因素，例如一致性测试 -Your project may also produce deliverables that are not software. If your project is producing documentation, discuss whether you should use a specific license for the documentation. For example, many open source projects will use an open source license for the software and a Creative Commons license for the documentation. Additionally, some projects seek to create specifications that may be implemented in various ways by others. Those projects should consider the option to use a specification license. +### 3.4.3 技术审查 -Each licensing approach has its advantages and disadvantages, but be aware of the potential for fragmenting your project, which is a particular problem for software that needs to be interoperable or provide portability across various vendor solutions. Often this issue is addressed by creating conformance programs that permit usage of the project trademark if the commercial solutions pass a community created test or set of requirements. Thinking about this up front will help inform your legal review and plans for the project. +技术审查验证源代码可以在不依赖于其他内部代码或开发实践（包括任何自定义内部构建系统）的情况下运行，并且不包含公司无法包含在开源版本中的第三方代码。 -In summary, the steps in the legal review process include: +技术审查应包括对所有许可和版权声明的验证，并应删除任何私人或内部代码注释。 步骤包括： -* Consider the impact of open sourcing on your company’s intellectual property -* Ensure full compliance with open source licenses -* Select an open source license for the source code to be released, document all licensing requirements very clearly in your project -* Decide if you need a contributor agreement -* Consider the possible non-software outputs from the community and the appropriate licenses, such as documentation and specifications -* Decide on any trademark related considerations -* Decide whether there are additional factors to build into your plans for an ecosystem, such as conformance testing +- 删除对非公共组件的关键依赖 +- 提供文档和用例示例 +- 删除内部注释、对其他内部代码的引用等。 +- 确保编码风格一致 +- 更新源代码文件中的版权声明 +- 在源代码文件中添加许可声明 +- 确保代码在任何外部目标平台上编译和构建 +- 将许可证文本作为文件添加到根目录中 -### Technical Review +### 3.4.4 营销审核 -The technical review verifies that the source code can function without dependencies on other internal code or development practices (including any custom internal build systems), and that it does not include third-party code the company cannot include in the open source release. +成功的开源项目不能完全依赖于代码和技术的优点——为了让项目继续前进，还有一系列额外的业务和营销步骤需要注意。它们包括推广项目、制定成功的运营战略、提供切合实际的预算和项目品牌，以及建立活跃的社交媒体帐户和有用的域名以支持长期成功。 -The technical review should include verification of all license and copyright notices, and any private or internal code comments should be scrubbed. Steps include: +营销审查为品牌建立了指导方针。这一点尤其重要，因为它有助于确保市场上的信息一致。营销审查的步骤包括： -* Remove critical dependencies on non-public components -* Provide documentation and use case examples -* Remove internal comments, references to other internal code, etc. -* Ensure coding style is consistent -* Update copyright notices in source code files -* Add license notice in source code files -* Ensure the code compiles and builds on any external target platforms -* Add license text as a file in the root directory +- 设计项目标志、配色方案、网站、宣传材料等。 +- 正式制定品牌指南 +- 为项目注册社交媒体帐户（Twitter、Facebook、LinkedIn 等） +- 为项目注册域名 -### Marketing Review +通过在项目启动之前执行此营销审查，您可以在任何潜在的品牌问题（例如您的首选名称无法使用域名）威胁到项目成功之前处理它们。确保您尽早与营销团队接触，以便他们可以帮助您解决这些（和其他）问题。 -Successful open source projects can’t live strictly on the merits of the code and technology alone - to keep the project moving along, there are a series of additional business and marketing steps that need attention as well. They include promoting the project, laying out a successful operational strategy, providing a realistic budget and project branding, as well as establishing lively social media accounts and useful domain names to bolster long-term success. +你可能会发现你的营销团队会很兴奋，因为看看你能带动多少人到项目中贡献代码、参与论坛、提供错误修复和报告问题是一个有趣的挑战。 -A marketing review establishes guidelines for branding. This is particularly important, as it helps to ensure a consistent message in the market. Steps in the marketing review include: +### 3.4.5 治理和流程 -* Design a project logo, color scheme, website, collateral, etc. -* Formalize branding guidelines -* Register social media accounts for the project (Twitter, Facebook, LinkedIn, etc.) -* Register domain names for the project +#### 3.4.5.1 治理模式 -By performing this marketing review ahead of the project launch, you can deal with any potential branding issues (like domain names not being available for your preferred name) before they threaten to derail the success of your project. Make sure that you engage your marketing team early on so that they can help you navigate these (and other) issues. +重要的是要考虑新的开源项目的治理模型。 但是我们所说的治理是什么意思？ 很简单，治理是围绕项目的结构，它支持以下方面的决策： -You’ll probably find that your marketing team will be excited, because it’s a fun challenge to see how many people you can drive to the project to contribute code, participate in forums, offer bug fixes and report issues. +- 参与指南和要求 +- 架构变化 +- 提名维护者 +- 争议的最终仲裁者 +- 暂停参与者 -### Lesson: Governance and Processes +有多种管理项目的方法，具有不同程度的业务和/或技术领导。 我们稍后将介绍领导力，但如果您想了解有关不同类型治理模型的更多详细信息，请参阅本培训系列中的“与开源项目有效协作”课程。 -### Governance Models +#### 3.4.5.2 领导力 -It’s important to consider what the governance model will be for your new open source project. But what do we mean by governance? Quite simply, governance is the structure around a project that enables decisions on: +在开始之前设定领导角色也很重要。对于不同的项目，这可能意味着不同的事情。如果您正在启动一个有多个企业参与者的多公司项目，该项目可能需要更正式的治理，例如管理委员会或其他管理小组。 -* Participation guidelines and requirements -* Architectural changes -* Nominating maintainers -* Final arbiter on disputes -* Suspension of participants +其他安排可能只需要一个技术委员会，从技术角度监督开源项目的所有方面。该委员会的组成将主要包括技术领导，以及与执行团队的联络人，以提供有关进展和项目需求的最新信息。然后可以在技术成员和高管认为合适的情况下引入法律团队。 -There are several ways that projects can be governed, with varying degrees of business and/or technical leadership. We’ll cover leadership in a moment, but if you want more details on the different types of governance models, please refer to the "Collaborating Effectively with Open Source Projects" course in this training series. +您的顶级架构头脑当然也会在那里，以及其他了解代码库将如何工作的人。总而言之，委员会成员将对项目的发展方向以及来自开发人员社区的支持有一个愿景。这些人是您希望在桌旁计划流程的人。 -### Leadership +#### 3.4.5.3 基金会或独立 -Setting leadership roles is also important before getting underway. That can mean different things for different projects. If you are starting a multi-company project with several enterprise participants, the project may need more formal governance, such as a governing board or other management group. +随着社区的发展，您需要能够适应任何新的沟通渠道。确保随着项目的发展，让您的社区参与工具决策——您可能会发现，如果用户和开发人员发现其他工具有用，随着时间的推移，他们自然会倾向于使用其他工具。 +创建新的开源项目时经常出现的另一个问题是，是将您的代码捐赠给与供应商中立的非营利组织，还是通过拥有和运行您自己的项目来保留一些控制权。答案取决于您想要实现的目标——如果您正在与少数合作伙伴合作为该行业构建一项新兴技术，您可能不需要在一开始就考虑成立一个非营利基金会。 -Other arrangements could simply require a technical committee that oversees all facets of the open source project from a technical perspective. The composition of the committee would include mostly technical leadership, as well as a liaison back to the executive team to provide updates about progress and project needs. The legal team can then be brought in as the technical members and executives see fit. +但是，如果您的计划在您的行业中具有广泛的适用性、跨行业，或者已经从小事发展成为大而复杂的事情，那么考虑一个非盈利的开源/开放标准联盟来托管您的项目通常是好的。项目。除了拥有真正的供应商中立场所来托管您的项目的价值之外，这些基金会还提供法律、治理、营销和项目基础设施服务，可以显着简化让您的项目走上成功之路的过程。 -Your top architectural minds will also certainly be there, as well as others who know how the code base will work. Altogether, the members of the committee will have a vision for where the project is going as well as support from within the developer community. Those are the people you want there at the table to plan the process. +您可以选择许多基金会（和子基金会），每个基金会都提供独特的价值主张、定价和服务水平。这些基础的一些例子是： -### Foundation or Independent +- Apache Foundation +- Eclipce Foundation +- Linux Foundation +- OASIS Open -Another question that often comes up as new open source projects are created is whether to donate your code to a vendor-neutral, non-profit organization or retain some control by owning and running your own project. The answer depends on what you are trying to achieve - if you are working with a small number of partners on building a nascent technology for the industry, you probably don’t need to consider a non-profit foundation at the beginning. +您选择哪个基金会取决于您的项目所在的专业领域，以及成本、治理模型等考虑因素。 -However, if what you are planning has wide applicability across your industry, is cross-industry, or has grown from a small effort into something large and complex, it’s often good to consider a non-profit open source/open standards consortium to host your project. Besides the value of having a truly vendor-neutral place to host your project, these foundations have legal, governance, marketing and project infrastructure services that can dramatically streamline the process of getting your project on the path to success. +### 3.4.6 技术流程 -There are many foundations (and sub-foundations) you can choose from, and each offers unique value propositions, pricing and service levels. Some examples of these foundations are: +在发布之前，创建一个标准的发布流程通常很有帮助，以便在项目维护人员进行更改和改进时安排代码的定期发布。应该为开发社区和项目的业务方面制定一个具有明确定义和可见细节的时间表。 -* [Apache Foundation](https://www.apache.org/foundation/) -* [Eclipse Foundation](https://www.eclipse.org/org/foundation/) -* [Linux Foundation](https://www.linuxfoundation.org/) -* [OASIS Open](https://www.oasis-open.org/) +发布这些版本的频率取决于您社区的期望。如果该项目以企业为中心，并且您正在尝试构建非常坚固的东西，那么您的发布时间表可能是一年两次。如果项目的范围更小、更敏捷，并且您正试图将其中的一部分发布出去，那么您可能会每月或每周发布代码。时间表的关键是社区必须规定时间表并从速度的角度了解其支持项目的能力，同时为用户提供他们需要和期望的东西。如果社区提供的反馈是发布过早或过慢，那么您需要查看流程并进行一些调整。这里最重要的是一致性、可预测性和可见性。 -Which foundation you choose depends on what area of speciality your project resides in, as well as considerations like cost, governance models, etc. +您还应该有明确定义的流程来提交代码、补丁、功能创意、文档或其他项目工件。其中一些可以在项目基础设施/工具中处理（我们将很快介绍一个主题），但技术过程的一部分不仅仅是工具，而是工作流程的期望 - 例如- 代码将如何提交，将遵循什么样的编码标准，新代码何时在发布周期中被接受等。 -### Technical Processes +## 3.5 项目基础设施 -Prior to launch it is often helpful to create a standard release process to schedule regular releases of the code as changes and improvements are made by the project maintainers. A schedule should be set up with well-defined and visible details for the development community and the business side of the project. +### 3.5.1 开发工具 -How often those releases should be made depends on your community’s expectations. If the project is enterprise-focused and you’re trying to build something that is very hardened, your release schedule might be twice a year. If the project is smaller in scope and more agile and you are trying to get pieces of it out there, perhaps you might be releasing the code monthly or weekly. The key to the schedule is that the community must dictate the timeline and understand its ability to support the project from a velocity standpoint, while giving users what they need and expect. If the community provides feedback that the releases are coming too soon or too slowly, then you need to look at the process and make some adjustments. The big thing here is consistency, predictability, and visibility. +在项目启动之前，您需要为项目准备一个存储库。这本质上是代码存储库的基础设施，项目将始终可供贡献者使用。许多项目使用著名的 GitHub 或 GitLab 存储库，或者使用 Gerrit 等工具托管自己的存储库。 -You should also have well defined processes for submitting code, patches, feature ideas, documentation, or other project artifacts. Some of this can be dealt with in the project infrastructure/tooling (a topic we’ll cover shortly), but part of the technical process is not just the tools, but the expectations of workflow - e.g. - how will code be submitted, what kinds of coding standards will be followed, when will new code be accepted in the release cycle, etc. +还有许多其他选项可用，但请记住，考虑让开发人员更轻松地参与和参与您的项目通常很有用。选择大多数开发人员熟悉的工具平台将有助于加快项目的贡献和增长。 -### Lesson: Project Infrastructure +错误、问题和功能跟踪也应作为项目基础设施计划的一部分。您希望为贡献者提供一个简单的地方来报告需要修复的问题以及对可能有用的新功能的请求。然后是自动化的构建和测试系统流程，它们可能需要包含在您项目的 GitHub 存储库中，以保持您的系统和项目流畅运行，同时扫描和检查代码以确保其质量。 -### Development Tools +通过查看本系列课程中的开源开发实践模块，您可以获得更多关于自动化测试和持续集成等方面的详细信息。 -Before the launch of your project can ever happen, you need to prepare a repository for the project. This is essentially the infrastructure for a code repository where the project will be available to contributors all the time. Many projects use the well-known [GitHub](https://github.com/) or [GitLab](https://about.gitlab.com/) repositories, or host their own repositories with tools such as [Gerrit](https://www.gerritcodereview.com/). +### 3.5.2 网站 -There are many other options available as well, but remember it’s often useful to consider making it simple for developers to participate and engage in your project. Choosing a tooling platform that is familiar to the greatest number of developers will help accelerate contributions and growth in your project. +关键的一步是为项目创建一个公司中立的网络形象。不要试图将开源项目网站作为公司网页的子域——即使你有最好的意图，项目中性主页的视觉区别也很重要。该网页为社区提供了一个查找项目信息的地方，包括文档、下载代码的链接等。该网页还可以提供有关项目领导、范围、用户和贡献者、预算、治理和其他详细信息的详细信息。作为中央信息存储库，您的网站还应该有非常明确的号召性用语/地点，供新开发人员加入社区。 -Bug, issue, and feature tracking also should be included as part of a project’s infrastructure plans. You want to provide an easy place for contributors to make reports of problems that need to be fixed as well as requests for new features that might be useful added. Then there are automated build and test system processes which may need to be included as part of your project’s GitHub repository to keep your systems and project flowing smoothly, while scanning and checking the code to ensure its quality. +### 3.5.3 通讯工具 -You can get more detailed information on things like automated testing and continuous integration by reviewing the _Open Source Development Practices_ module in this course series. +为您的社区提供沟通渠道以寻求帮助至关重要。您需要找到可以集成到整个开发工作流程中的工具（例如，接收支持请求通知、代码签入、错误日志和其他任务）。您还需要为社区成员提供重要的讨论论坛和机制，以便从同时参与项目的其他人那里获得快速答案。所有这些都是重要的沟通方式，有助于实时推进项目。 -### Website +要考虑的一个项目工具是 Slack，这是一个在线团队项目管理和通信平台，用户可以在其中访问和共享消息和文件、组织工作流程、执行信息搜索等。然而，Slack 是一种专有工具，超过一定的使用阈值需要花钱维护。有一些开源选项，例如 IRC、Gitter.im、Mattermost、Rocketchat 等。 -A critical step is creating a company-neutral web presence for the project. Don’t try to place the open source project website as a subdomain of a company web page - even if you have the best intentions, the visual distinction of a neutral home of the project is important. The webpage provides a place for the community to find information about the project including documentation, links to download the code, and more. The webpage can also provide details about the project’s leadership, scope, users and contributors, budget, governance, and other details. As a central information repository, your website should also have very clear calls to action/places for new developers to join the community. +根据您的开发人员和用户社区，您可能还需要现代论坛工具。 Discourse 是一个很好的选择，它是完全开源的，还提供可选的托管。选择通信系统时，请注意任何形式的锁定、财务成本以及将来迁移到新系统的难易程度。 -### Communication Tooling +随着社区的发展，您需要能够适应任何新的沟通渠道。确保随着项目的发展，让您的社区参与工具决策——您可能会发现，如果用户和开发人员发现其他工具有用，随着时间的推移，他们自然会倾向于使用其他工具。 -Offering communication channels for your community to ask questions for help is critical. You’ll want to find tools that can be integrated into the entire development workflow (for example, receiving notifications for support requests, code check-ins, error logs, and other tasks). You’ll also want to provide critical discussion forums and a mechanism for community members to get quick answers from others who are also working on a project. All are important means of communication that help move projects forward in real-time. +### 3.5.4 文档工具 -One project tool to consider is [Slack](https://slack.com/) , an online team project management and communications platform where users can access and share messages and files, organize workflows, perform searches for information, and more. However, Slack is a proprietary tool and can cost money to maintain beyond a certain usage threshold. There are open source options out there such as IRC, [Gitter.im](https://gitter.im/), [Mattermost](https://mattermost.com/), [Rocketchat](https://rocket.chat/) and others. +某种形式的文档管理通常对开源项目很有用，特别是如果它使创建文档、操作方法和其他基于文本的项目的过程变得更容易的话。 虽然许多项目都喜欢使用 GitHub 或 GitLab 的内置 Markdown 文本工具功能，但其他项目更喜欢使用 wiki 或其他共享编辑软件。 -Depending on your developer and user community, you may also need modern forum tooling. [Discourse](https://www.discourse.org/) is a great option that is fully open source and also provides optional hosting. When choosing a communication system, be mindful about any form of lock-in, financial costs, and how easy it is to migrate to a new system in the future. +有关潜在 Wiki 工具选项的列表，您可以查看（毫不奇怪）维基百科。 适用于通信工具的相同警告也适用于此 - 考虑如何避免任何类型的数据或工具锁定，以便当（不是如果）您的用户和开发人员决定迁移到不同的平台时，您可以迁移您的硬件 - 获得文档、常见问题列表和操作方法内容。 -As your community grows, you need to be able to adapt to any new communication channels out there. Make sure you involve your community in tooling decisions as your project evolves - you may find that users and developers naturally gravitate to other tools over time if they find them useful. +# 4. 成功的项目启动和维持 -### Documentation Tooling +## 4.1 简介 -Some form of document management is often useful for open source projects, especially if it makes the process of creating documentation, how-tos and other text-based projects easier. While many projects feel comfortable using the built-in markdown text tool features of GitHub or GitLab, other projects prefer using wikis or other shared-editing software. +在本节中，我们将讨论成功启动开源项目所需的最后步骤，并提供一些有关如何维持和鼓励采用和对项目做出贡献的附加信息。 -For a list of potential Wiki tooling options, you can check (not surprisingly), [Wikipedia](https://en.wikipedia.org/wiki/List_of_wiki_software). The same caveats that apply to communications tools also apply here - consider how you can avoid any kind of data or tool lock-in so that when (not if) you users and developers decide to migrate to a different platform, you can migrate your hard-won documentation, Frequently Asked Questions lists and how-to content. +## 4.2 学习目标 -# Section: Successful Project Launch And Sustainment +在本节结束时，您应该能够： -## Lesson: Introduction +- 描述成功启动开源项目所需的最后步骤。 +- 解释如何建立强大的社区流程，以提高项目的采用率和强大的贡献渠道。 -### Section Overview +## 4.3 项目启动 -In this section, we’ll discuss the final steps required for successful open source project launches, as well as present some additional information on how to sustain and encourage adoption and contribution to the project. +### 4.3.1 最终代码审查 -### Learning Objectives +在这个过程中的这一点上，最后一遍源代码以准备启动总是一个好主意。如果您一直遵循前面概述的过程，这应该不会是一个很大的负担，但是确保没有忘记任何易于修复的项目会非常有帮助。 -By the end of this section, you should be able to: +具体而言，此最终审查的目标应该是确保完全满足法律、技术和营销审查确定的所有要求。要查找的内容的一些示例是： -* Describe the last steps required to successfully launch an open source project. -* Explain how to build strong community processes that allow for increased project adoption and a strong contribution pipeline. +- 许可、归属和版权文本都完整且到位 +- 源代码扫描器报告干净的材料清单 +- 每一行代码都获得了适当的发布许可 +- 评论已清除随意或不相关的语言 +- 源代码不会无意中泄露内部项目 +- 源代码足够完整，可以构建 +- 使用公开可用的工具构建源代码 +- 文件和函数名称反映项目的名称（如果它已更改） +- MAINTAINERS 文件是最新的（如果使用） +### 4.3.2 预发布 -## Lesson: Project Launch +在您的新项目正式上线之前，您可以做一些事情来确保为您的组织和整个社区提供最佳的启动体验。为了确保成功，您可以做的最重要的事情之一是确保在发布之前拥有临界质量。 -### Final Code Review +当您宣布新项目时，您应该已经确定哪些合作伙伴和客户将与您同在。他们应该具有对存储库的预览访问权限，以便他们可以熟悉代码并准备贡献（或已经贡献）。 -At this point in the process, it’s always a good idea to take one final pass through the source code in preparation for launching. If you’ve been following the process outlined earlier, this shouldn’t be a big burden, but it can be very helpful to make sure that no easy-to-fix items haven’t been forgotten. +如果这是您早期的开源项目之一，那么与您自己的开发人员快速复习一下，以确保他们遵循开源开发方法和流程，以期与开源社区中的其他人进行交互也无妨将为您的项目做出贡献。 -Specifically, the goal of this final review should be to ensure that all requirements identified by the legal, technical, and marketing reviews are completely met. Some examples of what to look for are: +在您确认所有项目基础设施都已启动并运行后，请确保您的内部开发人员已加入项目的沟通工具并开始监控问题或新贡献。 -* License, attribution, and copyright texts are all complete and in place -* Source code scanner reports clean bill of materials -* Every line of code is licensed appropriately for release -* Comments are sanitized of casual or unrelated language -* Source code does not inadvertently reveal internal projects -* Source code is sufficiently complete that it will build -* Source code builds using publicly available tools -* File and function names reflect the project’s name, if it has changed -* MAINTAINERS file is up to date, if used +现在是重要时刻的时候了！您可以上传任何最终剩余的代码并翻转开关以使项目面向世界 -### Pre-Launch +### 4.3.3 良好的开源公民身份 -Before you go live officially with your new project, there are some things you can do to ensure the best launch experience for your organization and for the community at large. One of the biggest things you can do to ensure success is making sure that you have critical mass before launching. +现在您的项目已经启动，这只是未来工作的开始。您需要确保您的组织继续成为优秀的开源公民，并以鼓励其他人与您并肩并在您的项目上合作的方式运作。这里有一些方法可以做到这一点： -You should have identified which partners and customers are going to be there with you when you announce the new project. They should have had preview access to the repositories so that they can be familiar with the code and ready to contribute (or have already been contributing). +- 在公开场合进行对话并做出决定 + - 这建立了善意，并减少了记录决策的开销 + - 这简化了新参与者的入职流程 + - 拥有开放的档案可确保参与者发生变化时的连续性 +- 聆听社区 + - 他们的经验非常宝贵，尤其是在集成和测试方面 + - 鼓励扩展您需要的通用实现 +- 分配资源，就好像您将是唯一一家从事这项工作的公司一样 + - 设定目标，并确保他们有资源来完成 + - 在杠杆开发模式生效之前，这会形成动力 -If this is one of your early open source projects, it also doesn’t hurt to have a quick refresher with your own developers to make sure they are following open source development methods and processes in anticipation of interacting with others in the open source community that will be contributing to your project. +成为一名优秀的开源公民需要付出努力，而且这不是利他主义——对于您的组织来说，从您为启动开源项目所投入的投资中获得最佳回报是一种良好的商业实践。 -After you have verified that all of your project infrastructure is up and running, make sure that your internal developers have joined the project’s communication tools and are beginning to monitor for questions or new contributions. +# 5. 项目维护 -Now it’s time for the big moment! You can upload any final remaining code and flip the switch to make the project live to the world. +## 5.1 建立社区 -### Good Open Source Citizenship +项目启动后，监控外部开发者和用户社区的活力至关重要。社区建设不会自动发生。在项目的早期阶段，可能需要在主要会议上举办开发者活动或赞助聚会以建立动力。管理期望并履行项目治理和透明度的义务也非常重要。 -Now that your project has launched, it’s just the beginning of the work ahead. You’ll need to make sure that your organization continues to be a good open source citizen and operates in a way that encourages others to come alongside you and work together on your project. Here are some ways you can do that: +正在进行的活动包括： -* Have conversations and make decisions in the open - * This builds goodwill, and reduces overhead in documenting decisions - * This streamlines onboarding process for new participants - * Having open archives ensure continuity when participants change -* Listen to the community - * Their experience is invaluable, especially in integration and testing - * Encourage generalized implementations that extend what you need -* Allocate resources as though you will be the only company doing the work - * Set goals, and make sure they have resources to get accomplished - * This builds momentum until the leveraged development model takes effect +- 确保明确传达方向或治理的任何变化 +- 遵循其他类似社区的最佳实践 +- 鼓励和提供面对面社区建设的机会 +- 确定适当的活动并让社区提交演讲 +- 考虑举办本地聚会 -Being a good open source citizen takes work, and it’s not altruistic - it’s good business practice for your organization to get the best return on the investment you’ve put into launching your open source project. +通过建立一个多元化的贡献者群体，您可以稍后决定通过与其他认为这项工作有价值的企业和组织进行讨论，以确定他们是否有兴趣投入时间、金钱和其他资源，从而决定将您的项目提升到一个新的水平扩大您的初步努力。通过从其他人那里获得投入和资源，可以扩展和发展项目，以便为其他贡献者做更多事情。 -## Lesson: Project Maintenance +这种增长意味着更多的企业可能希望贡献更多的资金，让他们自己的开发人员加入进来，并通过将他们的力量放在你已经开始的努力上来帮助推进工作。这可能涉及 10,000 美元或 250,0000 美元或更多，具体取决于项目的重要性及其对其他公司的意义。一旦您的项目开始，其他公司可以进来为这项工作提供资金，如果这有助于他们的使命。 -### Build the Community +这在今天经常发生，因为企业和组织意识到他们试图解决的技术问题比他们单独的任何一个都大。那时他们可以开始看到在供应商中立的联合项目中与其他公司联合起来的战略价值，这些项目在解决企业面临的技术问题方面为更大的利益而努力。 -After the project has launched, it is essential to monitor the vitality of the external developer and user community. Community building does not happen automatically. In the early stages of the project, it may be necessary to host developer events or sponsor meetups at major conferences to build momentum. It’s also extremely important to manage expectations and fulfill obligations for project governance and transparency. +# 5.2 指定社区倡导者 -Ongoing activities include: +您可以聘请来帮助新的开源项目取得成功的最重要角色之一是社区倡导者（有时也称为社区经理）。这个人的角色是做任何需要让社区成功的事情。 -* Ensure any changes to direction or governance are clearly communicated -* Follow best practices of other similar communities -* Encourage and provide opportunities for face-to-face community building -* Identify appropriate events and have the community submit talks -* Consider doing local meetups +这是一个执行起来具有挑战性的角色，也可能是一个具有挑战性的角色，因为这个人需要各种各样的技能，包括营销、开发人员宣传、业务发展、危机管理、调解人等。一个开始寻找的好地方担任此角色的人员将考虑您组织中的内部开发或营销资源。此外，不要忽视技术作家、项目经理，甚至社会学、心理学等非传统研究领域的人。 -By building up a diverse group of contributors, you can later decide to move your project to the next level by having discussions with other enterprises and organizations that see the work as valuable to determine if they are interested in investing their time, money and other resources to expand your initial efforts. By gaining input and resources from others, the project can be expanded and grown to do more for additional contributors. +一个好的社区倡导者可以区分一个没有人使用的技术上成功的项目，一个相当好的技术项目，由于社区建设和部署的桥接技能而突飞猛进。 Linux Foundation TODO Group 是一个寻找社区管理资源帮助的好地方。 -Such growth means that additional businesses may want to contribute more money to bring their own developers in to join the efforts and help move the work forward by putting their weight behind the efforts you’ve begun. That may involve $10,000 or $250,0000 or more, depending on the importance of the project and what it means to other companies. Once your project begins, other companies can come in to contribute funding toward the work if it will aid their missions. +# 5.3 评估和适应 -This happens regularly today, as enterprises and organizations realize that the technology problems they are trying to solve are larger than any of them individually. That’s when they can begin to see strategic value in joining together with other companies in vendor-neutral joint projects that are working for the greater good in solving technical problems faced by businesses. +与任何新项目工作一样，如果您没有看到预期的采用和贡献类型，您需要经常评估并准备好调整您的方法。重要的是要记住，贵组织的声誉只是衡量新开源项目成败的一部分。 -### Designate a Community Advocate +当社区提供反馈时保持灵活性和敏捷性让您有机会提高项目作为协作和倾听的好地方的声誉。当您的项目开始时，您应该查看一些关键指标： -One of the most important roles you can hire for to help a new open source project succeed is a community advocate (also sometimes called a community manager). This person’s role is to do whatever is needed to make the community successful. +- 来自初始开发人员群之外的代码提交/拉取请求的数量 +- 关于您部署的任何通信渠道的讨论/主题数量 +- 提交的错误报告或功能请求的数量 -It’s a challenging role to execute, and can be a challenging role to hire for, because the person needs a wide variety of skills, including marketing, developer advocacy, business development, crisis management, peacemaker, etc. A good place to start looking for someone for this role is to consider internal development or marketing resources in your organization. Also, don’t ignore people like technical writers, program managers, or even non-traditional fields of study like sociology, psychology, etc. +同样重要的是要记住，即使是负面反馈也意味着您的社区正在参与您的项目。通过实践透明度和问责制并尝试公平地解决问题，您的项目将获得积极的声誉。 -A good community advocate can be the difference between a technically successful project that no one uses, and a reasonably good technical project that grows by leaps and bounds because of the community building and bridging skills deployed. The Linux Foundation [TODO Group](https://todogroup.org/) is a good place to find help in identifying community management resources. - -### Evaluate and Adapt - -As with any new project effort, you’ll need to evaluate frequently and be ready to adapt your approach if you aren’t seeing the kind of adoption and contribution you were expecting. It’s important to remember that your organization’s reputation is only part of the equation in the success or failure of a new open source project. - -Remaining flexible and agile when the community provides feedback gives you the opportunity to increase the project’s reputation as a good place to collaborate and be listened to. You should be looking at a few key metrics as your project gets off the ground: - -* Number of code commits/pull requests from outside your initial developer base -* Amount of discussion/topics on whatever communications channels you’ve deployed -* Number of bug reports or feature requests submitted - -It’s also important to remember that even negative feedback means that your community is engaging with your project. By practicing transparency and accountability and trying to fairly address concerns, your project will gain a positive reputation. - -Remember the adage that has been repeated throughout this training course series - ‘Release Early, Release Often.’ Your new project doesn’t have to be perfect on day one, but by keeping this adage in mind, you’ll be well on your way to building a successful and robust open source effort. +记住在整个培训课程系列中一直重复的格言——“尽早发布，经常发布。”您的新项目不必在第一天就完美无缺，但通过牢记这句格言，您将在构建成功且强大的开源工作的方法。