深度解读Eclipse SDV开源项目

对于汽车行业而言，2022年3月8日，或许是个值得铭记的日子。因为在这一天，Eclipse基金会在其官网宣布：由Bosch携手Microsoft等行业领袖倡议的软件定义汽车工作组成立了。这无异于在“软件定义汽车”的时代投下了一颗核弹！

太夸张了吧？我怎么一点都没听说？确实，可能人们的注意力都被俄乌战争吸引了（其实更想说我们对汽车软件行业的认识太浅了），这一重磅消息在行业内并没有获得大范围的报道，也没有引起大家的热议，很多人至今可能都还不知道，但并不妨碍称它为行业的大事件。为什么这么说呢？因为：

• 工作组的目标是为“软件定义汽车”时代的汽车提供开源、免费的通用汽车软件，即大家常说的广义的汽车操作系统，包括OS内核、中间件、云服务及开发工具
• 工作组的幕后老大是在汽车上开发软件最多的Bosch
• 工作组的核心成员有在全世界开发软件最多的Microsoft、世界上最大开源基金会之一的Eclipse，以及全球汽车零部件Top5中的三家：Bosch、ZF和Conti。
• 工作组将采用“Code First”的方法，一改以往先制定行业统一标准，各家再进行实现的汽车行业惯性思维。

在各大车企花费巨资打造自家操作系统甚至“全栈”汽车软件的今天，冒出来这样一个全明星团队要带领全球开源力量共同开发汽车操作系统，而且输出的是实实在在的源代码，而不是一堆标准文档，还说要无偿提供给所有人使用。这能不说是行业的大事件么？

毫无疑问，这对于无论是花巨资自研汽车操作系统的特斯拉、大众、上汽等OEM、还是QNX、Vector以及众多国内汽车基础软件公司、以及AUTOSAR、AUTOSEMO等标准化组织而言，都是一个关乎自家技术路线或产品路线的重大挑战，当然，或许也是一个重大机遇。

这到底是怎么回事呢？这事儿靠谱么？会带来哪些影响？以下仅基于有限的个人经验进行解读，难免有失偏颇，希望能抛砖引玉，引发行业同仁的更多思考。

一、这到底是怎么回事？

首先，我们看下这个SDV工作组的愿景与目标. 以下内容引用自官网中的工作组章程：

The mission of the Eclipse Software Defined Vehicle (SDV) Working Group is to provide a forum for individuals and organizations to build and promote open source software, specifications, and open collaboration models needed to create a scalable, modular, extensible, industry-ready open source licensed vehicle software platform to support in-vehicle and around the vehicle applications development and deployment.

The primary objective of the Eclipse SDV Working Group is to encourage, develop, and promote open source solutions that will be able to compete successfully in the challenging and fragmented markets of the automotive industry ecosystems around the globe. The working group will have a strong focus on implementation and onboarding of existing code artefacts from the working group members to build the ecosystem in a “code first” manner.

简单地说，就是联合个人和组织，以开源社区的组织形式，共同为“软件定义汽车”时代的汽车开发开源、免费的车辆软件平台，主要包含实时操作系统内核、中间件和通信协议栈等与应用功能无关，对OEM品牌差异化影响微弱的通用汽车软件，也可认为是汽车行业的基础软件。这一通用车辆软件平台将同时支持车端和云端上的应用，并提供配套的开发工具。

对于汽车行业来说，转向开源软件是对传统方法的彻底背离，简直就是“大逆不道”！要知道，Bosch过去一直在集团层面的内部质量规范中，明确要求关键车载控制器软件中不能含有开源软件，为此还在公司内部专门成立了开源软件审查团队，通过技术手段抽查各个项目的在此方面的合规性，从而避免开源软件使用不当而引起的核心技术的外泄。尤其是在与客户联合进行控制器内软件开发的项目中，由于外部软件的引入，这种IP泄露风险尤其突出。

这帮人疯了么？为什么会有这么大的转变？对此，我们将在下一节中尝试进行解读。

其次，我们看下这个SDV工作组的成员。根据工作组章程，SDV工作组会员分为五类：Strategic, Participant, Committer, Supporter 和 Guest。据项目组公开的会议纪要，截至5月份，成员规模已达到70家。下图展示了其中最为核心的Strategic和Participant 两类会员，共19家。

相比于AUTOSAR组织300多家的会员规模，当前的这个规模似乎还不足为道。然而仔细观察就会发现：

• Bosch和Microsoft，全世界最懂汽车软件和最懂IT软件的两家公司都在这里了，正印证了众人所说的汽车行业与IT行业需要深度融合。
• 会员不仅来自汽车行业，还涉及IT、云计算、芯片设计以及企业咨询等众多行业；显然，工作组正在为这一超级复杂的汽车软件平台构建一个巨大的生态。
• Eclipse是全球最大的开源基金会之一，具有丰富开源项目管理经验。这次被工作组邀请来作为“管家”，负责组织协调这一规模空前的超大开源项目，力争打造一个充满活力的开源生态。同时，Eclipse 中的项目都须遵循 Eclipse 公共许可证（EPL—Eclipse Public License）的规定，而EPL 是获得开源软件促进会（OSI—Open Source Initiative） 批准的常见开源许可证之一，属于弱Copyleft、商业友好型的一种开源许可证，有助于吸引更多的商业组织参与到开源社区。
• Red Hat，全球最大的开源解决方案供应商，正是这家公司用实际行动证明了通过免费的开源软件是能够赚到钱的。2018年IBM以340亿美元的价格将其拿下，这笔交易的规模在当时的美国科技界历史上能排进前三。Red Hat的加入或许更具示范效应。
• 有意思的是，大众、奔驰、宝马等自研OS的OEM以及QNX、Vector等基础软件供应商尚未出现在工作组成员名单上，或许他们对于在汽车行业搞“开源”这种“离经叛道”的行为，还需要更多时间再想想。

最后，也是最重要的一点，我们看下这个工作组的行事风格——Code First。Code First是什么意思？原来，汽车行业以往普遍都是“Document First”，比如AUTOSAR、OSEK/VDX、ISO26262、ISO21434等等，都是由各个联盟先制定一系列标准规范，然后各家遵照规范实现自己的软件，从而实现彼此兼容。在这种传统的方法中，人们见到代码往往是在联盟成立5~7年之后的事儿了，就像AUTOSAR。而Code First是指参与开源社区的各方把自己已有或正在开发的软件源码贡献出来，而无需先在联盟内达成普遍共识，从而呈现一种百花齐放、百家争鸣的充满活力的生动景象，同时也更加符合当下人们追求Agile（敏捷）的审美观念。

正因如此，ETAS说，SDV工作组与以往联盟最大的不同就是“Code First”。而以往之所以没有做到Code First，是因为大家普遍认为Code是核心Know-how，怎么能公开呢？正如AUTOSAR所倡导的“在标准上合作，在实现上竞争”理念背后所体现的：具体实现，即Code，是各家基础软件供应商的竞争力的体现。

除了涉及核心技术，经济效益则是另一个关键方面。据亿欧智库《2022中国智能电动汽车基础软件研究报告》预测，中国智能汽车基础软件市场2022年预计实现46.2亿元的市场规模，2025年汽车基础软件市场规模将达到142.5亿元。这么贵的东西，免费送？！

所以，如果要用一个词来形容Code First这一行事方法，估计只能用“颠覆”二字了。

二、这事儿靠谱么？

既然是“颠覆”，就不会那么容易。Eclipse基金会甚至将此描述为 “Open Source Revolution”¬——汽车行业的一场开源革命。

其实，这不是Bosch第一次针对汽车基础软件进行的开源尝试。

早在2013年，Bosch就已经强烈意识到，AUTOSAR标准虽然已经定义的非常细，但毕竟仍然只是个标准，而不是具体的代码。其所倡导的“在标准上合作，在实现上竞争”的理念，在实际落地过程中也出现了各种各样的问题，导致各家基于同一个标准开发的AUTOSAR产品彼此之间并不兼容，软件移植仍然困难重重，使得整车厂们的愿望被大打折扣。

站在Bosch的视角看，越来越多的车厂项目中要求在自己的控制器中集成第三方的基础软件，并使用相关的工具链，而不是自己原有的一套。这导致Bosch花费了极大的力气进行软件适配，而却很难从OEM那里收回这部分成本，更分散了本应用于在车辆应用功能领域进行创新的精力。

于是，Bosch带着自家孩子ETAS，牵头发起了一个类开源项目：COMASSO，以期联合各方共同开发一套符合AUTOSAR标准的基础软件及其工具。其背后的动机可参考如下来自其官网的描述。简单来说就是各家AUTOSAR产品没体现出水平差异，却带来了不小的集成工作量。为此Bosch建议大家共同来实现一套符合AUTOSAR标准的产品（common implementation）。

After 10 years of AUTOSAR development we observe the existence of various implementations without competition relevant differentiation, causing integration effort in case of SW exchange and reuse. We want to reduce this higher integration effort in case of SW exchange and reuse by supporting a common implementation of the AUTOSAR standard. This provides the members a higher degree of freedom to concentrate on innovation.

然而，一直视若珍宝的核心技术怎么可能舍得一下子全送出去。最终，身体比大脑更诚实：由于“半遮半掩”的不彻底开源，以及对开源项目运作经验的缺乏，该项目并不成功。从2013年Bosch和ETAS共同成立COMASSO开始，这个项目已运行近十年，仅有20多家组织加入，目前依然不温不火，知名度很低，影响力有限。

有关汽车基础软件诞生与演化的更多信息，可参考本人的另一篇文章《汽车基础软件漫谈》。

但失败是成功之母，或许正是这一次的失败让Bosch找到了成功所依赖的三大要素：天时，地利、人和。

首先说天时。今天，相对于COMASSO成立时的2013年，软件定义汽车的理念已经成为行业共识，而大众、宝马等诸多头部企业的实践也已初步证明，要想靠自己来实现太难了，大家必须齐心协力，共同合作。

对此，Bosch汽车事业部副总裁 Sven Kappel表示：一个开放的生态系统是SDV成功的关键。也正是基于这样的考虑，Bosch强烈倡议共同成立了这个工作组。Conti汽车业务CTO Gilles Mabire说：开放协作对于构建基于软件的创新，并将其迅速推向市场至关重要。微软负责云架构和人工智能的Ulrich Homann表示：在跨行业的开源社区中合作为公司提供了一个独特的机会，可以更好地满足不断变化的客户需求。

Eclipse基金会则表示：正如 OSS 在制造和医疗保健等其他行业实现了快速创新和规模化一样，汽车行业也将从利用开源模型中受益。为工作组的首次启动而聚集在一起的行业领导者充分说明了对该计划的需求。

而从反面看，去年9月，BMW CTO Frank Weber说：当每个人都开发自己的操作系统时，这是一个错误，这是一条死胡同，这样做，我们正在危及德国、欧洲及其他地区成熟的供应商网络。BMW CEO Oliver Zipse则对此表示同意，他说：在中央操作系统方面，合作是有意义的，我们会明确支持这一点。

不难看出，经过大家近几年的尝试，越来越多的大型组织认为需要构建一个开放的生态，联合进行汽车基础软件的开发，行业共识基本形成。

再说地利。Bosch和Microsoft分别作为全世界最懂汽车软件和最懂IT软件的公司，在软件开发方面具有丰富的经验，实力毋庸置疑。软件是他们的看家本领，绝对主场。

同时，二者也都不生产整车。Bosch一直坚持不造车，服务别人造好车，自不必多说。而MicroSoft是少数没有自己的汽车项目的科技巨头之一。谷歌姊妹公司Waymo和苹果正在开发自己的自动驾驶软件，亚马逊收购了机器人汽车公司Zoox。同时，Microsoft一直强调它不想与客户，即汽车公司竞争。而事实也表明，MicroSoft主要基于Azure云平台为汽车行业的客户提供服务。这或许也是Bosch选择与Microsoft深度合作的原因。

最后来看人和。充满活力的开源社区是开源项目成功的关键，而凭借 Eclipse 基金会对透明度、供应商中立性和共同发言权的承诺，使得所有参与者都有平等的机会塑造 SDV 工作组的未来，打消了同行的戒备之心。因此，我们看到，虽然工作组是Bosch倡导建立的，但作为竞争对手的ZF和Conti也加入了工作组。

同时，Bosch和Microsoft两大巨头的带头示范效应也必将极大地帮助社区凝聚人气，吸引来自汽车和IT两大行业的更多重量级组织参与。

Eclipse基金会拥有成熟的大型开源社区治理模式，相信在Eclipse基金会的专业运作下，社区将不断壮大，人气将越来越旺。

三、会带来哪些影响？

影响主要是由于采用“开源软件”这一模式所带来的，因此，我们需要先对开源软件有一个透彻的认识。以下内容主要参考了《开源软件之道》一书，该书写得非常好，强烈推荐！

首先，有必要先明确下什么是开源软件。因为很多人会将开源软件（Open Source Software）和源代码开放的软件（Software with open source）、免费的软件（Software of free charge）、自由的软件（Free Software）等概念相混淆。

开源软件通常可以理解为能够自由地获取、修改和重新发布源代码的软件。对于没有商业目的的个人使用者来说，这样简单的理解开源软件也是可以的，但是，企业用户及需要参与开源项目的开发人员，就必须对开源软件有更深刻的理解，需要认识到使用开源软件和参与开发开源软件时潜在的法律因素。

开软软件促进会OSI对开源软件有明确的定义，业界公认只有符合这个定义的软件才能称为开源软件。这一定义共有十个条款，下面是简要介绍，更多详细内容可参考《开源软件之道》一书。

1. 软件允许自由再发布
2. 软件必须包含源代码
3. 软件允许修改和派生作品
4. 软件要求保护作者源代码的完整性
5. 不能歧视任何个人和团体
6. 不能歧视任何领域
7. 开源许可证不得被附加条款覆盖
8. 许可证不能只针对某个产品
9. 许可权不能约束其它软件
10. 许可权必须独立于技术

OSI推出的这一“开源软件”概念继承和发扬了自由软件的开放、分享的精神，同时对自由软件中过于严格的传染性进行了修正，保证了商业公司在参与和使用开源软件过程中可以保护自己的利益。

Eclipse基金会为旗下开源项目所制定的公共许可证EPL正是经过OSI认可的一种常见开源软件许可证。正是有了这样一个清晰而完整的许可证，在法律层面保证了开源软件的开放性、独立性和可继承性，众多商业公司才没有了后顾之忧，纷纷加入进来，使得各种开源软件项目不断涌现。

其次，开源软件的使用并不是零成本。开源软件的应用通常可以降低企业成本，但并不意味着开源软件与免费或者低成本之间存在必然联系。实际上，使用开源软件也会有成本，这些成本大致可分为如下四类：

• 部署和迁移成本。在软件成功运行之前，开发人员需要根据自家产品特点，进行系统配置、集成与调试等大量适配工作，对此，嵌入式Linux工程师们肯定深有体会。而这个过程常常由于帮助文档的零散和不全面，以及缺少有经验的使用者指导而变得非常痛苦，令人沮丧。商业软件往往更注重用户体验，这方面做的较好，用户可以省心不少。
• 人员和培训成本。在人才市场上，有开源软件使用经验的人本来就极少，更不用说对于SDV这一系列新创建的开源项目。因此，企业必须花更多的钱才能雇佣到会使用开源软件的员工或者去培训已有员工让他们掌握开源软件的使用技能。当然考虑到商业软件所需的持续按年计费的软件许可费或者维护费，甚至强迫性的软件升级费，从长远角度看，培训自己员工使用开源软件会更省钱。
• 管理维护和技术支持成本。软件总的持有成本更多来自软件的使用过程，包括软件的管理维护和技术支持。而这部分费用的评估是非常复杂的，相关的因素很多，包括软件的稳定性、易用性、安全性、升级补丁的发布频次、是否有可视化或其他高效的管理工具、企业员工的能力水平等。因此很难有一个简单的定论。Yankee Group的资深分析师Laura DiDio曾做过研究，发现大规模部署Linux操作系统相比于商业的Windows和UNIX操作系统，需要增加25%~40%全天候技术支持帮助用于解决使用问题。当然，商业软件如需持续服务通常也需要交年度维护费。
• 风险控制成本。开源软件是潜在的法律纠纷多发地区。市面上的开源许可证数量众多，要解读这些许可证的条款并不简单。最著名的案例要数2003年SCO起诉IBM将其部分UNIX源码捐献给了Linux操作系统，侵犯了其知识产权，要求IBM赔偿10亿美元的损失。好在经过数年诉讼最终裁定无需赔偿。最近，因俄乌战争，人们也开始意识到，原来有些开源许可证要求被欧美制裁的国家或组织也不得使用其开源软件。因此，为了控制风险，在选用开源软件时，应该建立严格的评估流程。而这显然也是成本。如果使用商业软件，这种法律风险通常由软件供应商承担，用户则可以省很多心。

最后，通过商业模式创新，基于开源软件也可以获得商业利益。以下介绍两种比较流行的商业模式：

• 增值产品。开源项目以一种松散的组织结构依赖爱好者的主动参与进行软件的开发，开发出的软件产品也都以“如现状”（AS IS）的方式发布，即不提供任何质量承诺和担保。导致用户，尤其是企业用户无法大胆使用。因此，许多厂商便通过向用户提供开源软件的增值产品来营利。Red Hat就是其中著名的一家。

Red Hat的商业模式是一种专业化的开源运营模式，即基于开源的代码、社区化的开发、专业化的质量保证服务以及可订购的客户技术支持服务，向用户发行经过其增值后的Linux发行版，即RedHat Linux。

Red Hat 积极地参与Linux Kemel和相关软件的开发，在Linux社区中具有相当大的影响力，可以在一定程度上影响其参与的开源社区的决策和发展，在开源软件产业链的源头具有一定的控制力，从而能够对客户的需求和反馈做出迅速的反应和处理。

实际上，近几年，随着在云计算、大数据领域的业务拓展，Red Hat已经成为全球最大的开源技术厂家，并被IBM在2018年以340亿美元的天价收购。它所创造的“商业开源软件的模式“成功证明了“开源是桩好买卖”。有兴趣的读者可以自行查阅相关资料。

• 产品服务。提供增值产品往往伴随着产品服务，但也有些公司则比较单纯地围绕开源软件提供服务来营利。产品服务的形式主要有技术支持和咨询两大类。下图展示了IBM为开源产品WASCE所提供的产品服务及报价。服务形式包括现场支持、顾问引导、快速上手以及交互式讨论等。

除以上两种主要模式外，还有广告模式、软硬件结合、双重授权以及社区模式等多种，限于篇幅，不再赘述，感兴趣的读者可参阅《开源软件之道》一书。

总之，通过服务商业化，开源软件完全可以拥有自己的商业模式，更好地发展自己，扩展和提高软件的功能，更好地提供服务。

理解了以上开源软件的特点，再来分析这次事件所带来的影响就容易些了。但在VUCA时代做预测仍是非常困难的事情，以下仅代表个人部分浅见，希望抛砖引玉，不足指出，欢迎大家指正。

第一，原来那些“Document First”的组织，如AUTOSAR、SOAFEE、COVESA还有生存空间么？个人认为是有的，他们并不会消失。因为SDV工作组也强调，他们不主张“Re-invent the wheel”。但由于“Code Fisrt”的巨大颠覆性，如果成功，Code将成为事实上的标准，就如同Andorid，有没有那些标准文档或许已经不重要了。

另外，还有人可能说，怎么有些企业同时存在于多个不同的联盟中呢？脚踩N条船！实际上，屁股决定脑袋，不同的企业在产业链中的不同位置都有各自不同的利益。在一个联盟中并不代表就完全支持这一联盟。比如Bosch加入AUTOSAR就不是心甘情愿的，对此，感兴趣的读者可以参考本人另一篇文章《薄弱的国产基础软件，能在汽车行业逆转么？》（配文章链接）

第二，Vector、QNX、ETAS等现有汽车商业软件以及VW、特斯拉自研的OS还会有市场么？个人认为也是有的，但肯定会受到巨大冲击。尤其是对于一些产品质量、工程服务不好的产品。毕竟，很少有人能抵挡“免费”的诱惑，而商业软件如果能提供比开源软件更高质量的产品与服务，也将同样占有一席之地。这大概就像Windows之于Linux，iOS之于Android吧。

第三，现在绝大多数车企都抱有类似上汽“灵魂论“的想法，他们会接受这种开源方案么？个人认为大多数会接受的。其实，汽车基础软件也好，操作系统也罢，这些都是Application-independent的，不属于应用软件，不会阻碍OEM打造自己有别于他人的差异化特征，即灵魂。

在前面提到的本人另一篇文章中，提出了 汽车基础软件相当于ECU的“神经系统” 的观点，而灵魂则是更上一层的内容。大脑（应用软件）通过神经系统（基础软件）来获得身体（硬件）所感知到的外部信息，并在分析决策后通过神经系统（基础软件）来控制身体（硬件）做出各种动作。

所以，车企在采用统一的开源解决方案后，反而可以腾出更多精力用于真正关乎用户体验的创新型应用功能的开发。除非OEM软件开发能力特别强，现有开源方案无法满足需求，而自己也有能力打造类似iOS这种独一无二的操作系统，可以认为是一种更高级生物的神经系统。

最后，对国内的汽车基础软件参与者会有哪些机遇和挑战？可以肯定的是，机遇远大于挑战。就像Linux操作系统这样高质量的开源软件一样，一旦开源，将立刻将国内与国外拉到同一起跑线。这为国产汽车基础软件的发展带来了一种全新的可能。

但是，在击掌相庆的之时，更需要清晰地去认识这个新游戏的规则。目前国内开源软件的发展情况并不乐观，特别是参与社区的深度和广度更是被国外同行广为诟病。套用一句广告语：“我们不生产代码，只是代码的搬运工”。习惯了“拿来主义”的同胞们如果不能遵守这些规则，不能真正融入到这场波澜壮阔的开源革命中去，那么最终将再次错失这一千载难逢的发展契机，那将是举国之憾。

正如中汽协董扬老前辈在《中国汽车操作系统发展初探》中提到的：

在过去的70年里，中国汽车产业向世界汽车产业学习、引进了大量的先进技术。这符合产业规律和国际规则，我们也应该心存感激。现在，中国已成为世界汽车第一产销大国，科技投入、人才队伍都位居于世界汽车产业前列，中国已有良好的汽车原创技术发展条件，中国理应自主开展汽车操作系统研发工作，为世界汽车产业发展做出自己应有的贡献。

希望我们能抓住这一机遇，不仅仅为了解决“卡脖子”问题以实现产业安全，更是为全球汽车软件产业发展贡献中国力量，体现大国担当。

四、尾声

俗话说得好：Talk is cheap, show me the code. 说了这么多，会不会雷声大，雨点小，半行代码都见不到？

别着急，6月30号，SDV工作组将举办首个“Contribution Day”，届时，SDV工作组将介绍已收到的一些开源项目建议及项目代码开发情况，从而展示“Code First”口号是如何落地的。 同时，也会对“Code First“的这一理念进行官方阐述，并介绍工作组年度工作计划，工作组与开源项目的关系，项目上线流程、以及工作组公开运作的基础设施。

到底这些巨头会拿出多少诚意，让我们拭目以待。发烧友也可以登录官网申请加入SDV工作组的Mailing list，第一时间了解最新动态。

欢迎扫码进入专属交流群：

参考文献：

1. Eclipse SDV工作组官网：sdv.eclipse.org
2. AUTOSAR官网：www.autosar.org
3. COMASSO官网：www.comasso.org
4. 蔡俊杰，《开源软件之道》，2010
5. Eclipse,《Eclipse Software Defined Vehicle Working Group Charter》，2022
6. Eclipse, 《The Eclipse Foundation Joins Bosch, Microsoft, and Other Industry Leaders to Create an Open Source Working Group for the Software-Defined Vehicle》，2021
7. 汽车制造AP, 《新的开源计划启动：博世、大陆及采埃孚等供应商和微软开发统一的操作系统》，2022
8. 董扬汽车视点，《中国汽车操作系统发展初探》，2021