三星的开放生态系统

在过去的五年里，三星投入了大量精力来建立团队、文化和流程，成为开放生态系统的积极贡献者。那么，为什么一家硬件公司会进行这样的投资？其价值何在？我们如何将硬件差异化与开源和标准结合起来？

在这篇博客文章中，我们尝试澄清这些问题。具体来说，我们将详细介绍：(i) 对三星而言，开放生态系统是什么，(ii) 为什么我们认为通过标准和开源的开放性很重要，(iii) 硬件与生态系统协同设计如何成为硬件供应商成功的关键，最后 (iv) 回顾三星建立开放生态系统团队的历程以及在过程中获得的经验教训。

1. 硬件公司中的开放生态系统？

在解释开放生态系统的作用之前，我们先花一点时间来定义它。在三星，我们将“开放生态系统”（通常内部简称为 eco）定义为标准、开源和行业协同的结合。客户解决方案则是硬件和生态系统的总和。

• 开源 :  对于我们来说，开源严格指的是那些被广泛使用的、主流的开源项目，并且这些贡献会被合并到上游代码中。我们不认为分叉项目并在其上添加功能能够真正为开放生态系统做出贡献。分叉可以是开发新功能的一种方式（我们确实这样做！），但最终目标始终是将代码推送到上游并合并到主线中，以便通过企业发行版提供。在少数情况下，我们确实会启动新项目，以支持不同客户的需求，同时保持健康的社区氛围。一个例子就是 xNVMe。

• 标准 :  我们参与了多个与我们产品相关的标准机构，并在其中一些机构的领导团队中进行贡献和参与。

• 行业协同 :  在开源和标准化工作中，一个主要挑战是共同基础设施应能够涵盖多个用例。这涉及三个方面的问题：(i) 不同公司可能有共同的用例，但内部采用不同的处理方式；(ii) 标准支持的新功能可能对一个或多个公司有意义，但对开源项目所需的更改可能会带来重大变化；(iii) 不同公司在相同或不同的标准机构中实现了类似但不完全相同的方法来解决相同的用例。在这些情况下，行业需要进行权衡和妥协，以便覆盖尽可能多的用例，同时使项目和标准易于维护。

通过将生态系统视为这三部分的结合，我们在设计新产品功能时做出了前期决策，将其视为社区努力和内部推动提供最佳硬件解决方案的结合。当我们提议或支持新功能时，我们与同行、竞争对手和客户在开放的会议、委员会和标准机构中合作，做出正确的权衡，以便最终功能能够支持尽可能多的用例。然后，我们承诺在主流开源项目中支持客户，推动必要的更改上游，并与社区合作，使代码变得有用和可维护。

当一种新技术出现时，少数先锋企业通常会构建垂直解决方案，这些方案紧密集成了硬件和软件，通过提供新的功能来作为差异化因素，但代价是将消费者锁定在单一来源上。然而，随着技术的成熟，围绕它存在一个开放生态系统是广泛采用的必要条件。以 NVMe 为例，最早的 PCIe NAND 版本依赖于供应商特定的协议和专用软件来操作硬件。一个先行者是 Fusion I/O，它生产了 PCIe 附加的 SSD 和基于主机的闪存转换层（FTL）。这种解决方案的性能前所未有，因为一般可用的 SSD 通过 SCSI 通信。随着更多供应商进入 NAND PCIe 市场，对标准的需求逐渐出现，逻辑设备接口规范（NVM Express，简称NVMe）协会应运而生。如今，NVMe 是 PCIe 附加非易失性介质的主要协议，而围绕它的开放生态系统确保了供应商和消费者可以依赖一个快速、安全、稳定的软件堆栈，这个堆栈能够支持规范的最新补充。我们在行业的不同领域中反复看到这一点。我们认为，这主要有三个原因：

• 供应链与多供应商 : 当一种新的差异化技术出现时，成为首发者的好处往往超过了依赖单一供应商的风险。随着更多供应商进入市场，差异化因素逐渐稀释，单一来源的风险通常是不值得的。问题在于：供应商如何围绕一个协议对齐、满足消费者的行为预期，同时管理自身进入全新技术的风险？答案是标准、开源和一个开放的行业社区来理解共同的使用案例。除了分散风险，开放合作还完全消除了信任缺失问题。这个开放生态系统为消费者提供了稳定的多供应商供应链，并减少了供应商的硬件碎片化，有效地减少了需要验证和认证的库存单位（SKU）数量。

• 软件稳定性、安全性和中立性 : 依赖主流开源项目来支持标准具有固有的软件质量。这些项目，如 Linux 内核，在合并新补丁之前实施严格的代码审查过程。此外，多家公司和企业 Linux 供应商在其上运行持续集成，以防止回归问题。此外，主流项目通常由那些在添加功能时能够保持中立立场的个人维护，这些人通常知道如何保持代码库的稳定性。由于讨论总是在开放的论坛中进行，任何偏袒某个公司的迹象都是非常罕见的，通常会在特定的开源社区中得到解决。这允许供应商和消费者发送补丁来支持标准的新补充。需要注意的是，我们在这里指的是核心、基础设施开源项目（例如 Linux 内核、核心库、工具链），这些项目为硬件支持提供了基础。在此基础上，消费者通常会添加其差异化的软件和服务，这些是他们自己的客户所增值的部分。

• 新技术采纳的共享风险 : 向硬件产品添加新特性是一个需要多年的努力和大量投资的过程。支持不同客户的不同需求会增加复杂性和碎片化，从而使这一投资变得不可持续。标准有助于解决这一问题。虽然将特性添加到标准中也是一个多年的项目，但厂商和消费者需要在开放环境中达成一致并进行权衡，这样可以减少错误和碎片化，使得一个特性可以同时针对不同的用例。这种情况在这些特性被实现到主线开源项目中时尤为明显，因为不同公司会合作加速特性的采纳。在硬件产品上市时，生态系统已经到位。这将风险分摊到多家公司之间，使得更复杂的特性得以成功部署。

2. 硬件与开放生态系统共同设计

硬件与开放生态系统共同设计是这一思维方式的自然演变。这涉及到在硬件特性构思阶段就考虑其周围的生态系统，并定义硬件如何作为业务战略的一部分得到支持。为了达到这一点，我们看到厂商需要经历两个不可并行的阶段。

第一个阶段是从硬件到生态系统的转变。这是将开放生态系统视为支持硬件特性的工具。大多数硬件公司以这种方式开始其在开源和标准方面的旅程：他们为其SoC（系统芯片）提交驱动程序，启用驱动程序中的现有功能，或将新开发的标准功能贡献给核心子系统。大多数硬件公司理解这样做的价值，并以某种方式希望成为支持其领域内硬件的开放社区的一部分。这些公司明白，实现大规模采纳的路径是通过上游Linux社区。

如果止步于此，则会带来以下几个挑战：

• 特性回声室 : 当厂商通过硬件到生态系统的视角来看待世界时，他们所看到的只是如何通过硬件架构增加新特性并区分自己的产品。通常，这些进步是内部团队提出优化和客户提出新用例的组合结果。在这种情况下，硬件特性被设计和实现。在最坏的情况下，硬件在公司内部还没有人审视这些特性如何融入生态系统时就已经完成生产。你需要非常幸运才能让这个过程最终形成标准，并纳入任何主线项目。通常，这会导致SKU（库存单位）碎片化，因为硬件仅针对特定客户，并需要专门的软件栈来支持。

• 行业不对齐 :  当一种新技术成为主要的差异化点时，一些公司往往会对行业和开放社区的反馈视而不见。这可能是由于对用例的误解、对技术实际价值的夸大，或低估了支持该特性的标准或开源项目的变更范围。与行业的不对齐是有风险的，因为它会给社区带来压力，要求支持一种最终没有被使用的技术，并继续在项目演进中进行维护。

• 信任缺失 : 最终，上述所有问题会导致公司失去社区的信任，因为它被视为只关心推动自身特性，而忽视了对社区其他部分的影响。尤其是在主线开源项目中，维护健康的代码库比支持最新的协议特性更为重要。

第二个阶段是从生态系统到硬件的转变。这是通过理解开放生态系统中可以从更好的硬件和软件交互中受益的用例来定义硬件需求。在这里，需求是在观察到生态系统中的一个问题后引入到硬件中的。关键点在于，这可能不是客户明确识别的问题（因此被请求），而是一个被广泛理解并且最终需要解决的已知烦恼。因此，企业内部需要对开放生态系统有深刻的理解，因为新特性将基于这一理解在硬件中实现。此外，一旦生态系统成为产品战略的一部分，企业自然会为标准或开源项目的健康发展做出贡献，即使这对所有人都有好处，因为这些项目被理解为业务成功的关键因素。

3. 全球开放生态系统团队（GOST）

在三星，我们建立了一个专门的团队来推动这一努力。我们称之为GOST：三星全球开放生态系统团队。最初，GOST代表全球开源团队；随着范围扩展到更多的生态系统活动，我们进行了调整。

GOST是一个全球分布的团队，专注于生态系统的不同方面。

 

我们为多个开源项目做出贡献，包括Linux内核、QEMU和SPDK。在这里，我们不仅仅贡献代码和承担维护责任，还积极参与推动社区的发展，担任多个开源组织委员会、领导委员会和会议组织机构的成员。

除了确保代码的高质量，我们的另一个重点是关心代码背后人员的福祉。整个开源社区本质上是一个很好的工作场所，尽管我们有时会面临激烈的讨论，我们认为这主要源于两方面的原因：(i) 我们的维护者承受的压力，包括处理大量日常补丁并确保项目的推进；(ii) 我们在公开场合进行所有对话（包括困难的对话）。在这种背景下，我们花时间指导新的成员（无论是内部还是外部的）如何开始贡献代码以及如何应对严格的代码评审。

作为一个高度分布的团队，我们在韩国、美国、印度、中国、以色列和欧洲（丹麦）均有存在，这些地点涵盖了三星在全球最大的开发中心。我们相信，这对于实现我们雄心勃勃的生态系统愿景至关重要，原因有三个主要方面：

• 关注对齐与角色与责任 : 领导一个分布式团队要求明确关注对齐而不是任务管理。这有助于培养良好的文化，领导者提供业务和产品方面的重要性明确性，而不同的生态系统团队则可以推动计划和执行。由于同一项目中的团队可能分布在不同地区，定义角色和责任（RnR）是自然的。在三星，我们的战略是不断调整GOST的活动与业务战略的对齐，然后向团队提供明确的指导，这成为我们的战术和执行的一部分。

• 本地化需求 : 尽管分布式工程团队可以高效运作，但在规划、生态系统和产品（硬件 + 固件）方面推动一个完全分布的垂直战略仍然是一个挑战。这在生态系统团队是唯一的分布式团队的地方尤为明显（这种情况相对较为常见）。面对面的互动、白板讨论或单纯的人际交流在推动新的雄心勃勃的项目时发挥了重要作用。在三星，我们从一开始就设计了GOST为分布式团队。大多数成员靠近开发中心，但我们也有完全远程的同事。我们相信，维护一个能够与相关本地团队互动的分布式团队对长期成功至关重要。

• 获取全球人才 :  这是一个“在人才所在之处招聘人才”的老问题。开源生态系统社区早在多年前就开创了远程工作模式，由于这是我们针对GOST的人才池，我们自然会遵循这一理念。

4. 接下来会有什么？有新伙伴加入吗？

对于我们来说，下一步是继续推进现有工作，同时将团队扩展到更多领域。我们很幸运，三星是一家拥有多个业务单元的大公司，这些单元都可以从理解和贡献开放生态系统中受益。

对于外部的下一步，我们希望看到更多硬件厂商积极参与标准制定和开源项目。在会议上，我们经常遇到业界同事，他们称赞我们的工作或报告我们和其他人完成的工作的上游问题。尽管我们乐于看到社区的努力获得认可，并享受修复社区报告的问题，但我们希望这些公司能够积极参与，并将对话带到公开论坛上。这将有助于解决前文提到的回声室和行业不对齐问题，从而使更多技术获得成功。如果没有其他收获，我们希望这篇文章能为如何入手提供一个蓝图。

最后，这篇博客文章是GOST内部新博客计划中的第一篇。我们计划发布关于我们认为重要的技术内容，重点关注开放生态系统。我们计划每6到8周发布一篇深入的文章。如果你觉得这很有趣，敬请关注！