bored兄这开源水军经验谈绝了！从前我们工地也搞过“自主研发”光伏逆变器，改个界面logo就挂羊头卖狗肉…后来发现有些老哥真能看懂底层逻辑，调试CAN总线比解数独还上瘾哈哈。你说那六成占比难界定，不如问问他俩月后更新OTA会不会悄悄塞进新模块？

哈哈你这制茶的比喻比那帮开口闭口就谈代码行数的实在多了。说起来我在柏林常去的那家爵士酒吧，老板是个六十多的越南裔，老头泡茶那叫一个讲究，有次跟我说，茶汤分三层，浮在上面的叫云，第二层叫雾，最底下那叫韵——我看开源社区也是这么回事，有人喝的是云，有人喝的是雾，能不能品出韵，得看各人造化了。ES9这泡茶，且得喝一阵子才知真假。

random_hk 你这规矩定得硬啊，"黑箱调用"这词儿我跟我们小区物业说去，他们查监控都懒得调
对了
不过我有个疑问，你那规矩多花的三成时间，甲方乐意掏这个钱不？我当年在部队搞后勤，上面也说要自研系统，结果最后还不是买了套现成的改改界面，验收的时候领导还夸"界面很清爽"哈哈

钓鱼时候倒是认识一老哥，在比亚迪干过，说他们那套DiLink早期也是各种开源拼起来的，后来想慢慢替掉，发现跟拆炸弹似的，一动就报错 你说这算不算另一种"书奴"，奴久了离不开了

你带团队时候，有没有遇到过那种"这玩意儿开源的肯定没问题"然后半夜爬起来救火的情况？

random_hk你这个“必须有人能读懂核心逻辑”的规矩我太熟了！之前我在FAANG带过一个项目，组里有人从GitHub扒了个调度算法，跑起来看着没问题，结果上线两周内存泄漏直接崩了——最后发现人家那个库的注释里写了“not for production use”。从那以后我立了个规矩：谁用开源组件谁负责写十行注释解释为啥选它，写不出来就别merge。这波操作虽然让PR review时间翻倍，但至少不用半夜爬起来修bug了哈哈。

楼主说书法临帖 我倒是想起店里那套开源点餐系统 改着改着就变成自己的配方了 车机大概也是这么个道理 改出自己的味道才叫本事

你们知道吗，我那个在Morgan Stanley做tech coverage的前同事，去年偷偷跟我讲过一个事。蔚来当时挖了整套AOSP的团队，薪资包开得特别aggressive，条件之一就是要求签竞业的同时，必须把之前参与过的开源项目commit history"优化"掉。所以那个六成，你们懂的，可能水分比想象中大。

嘿嘿不过我更在意的是Apollo那部分。百度自己都在慢慢往封闭了走，ES9如果真的还按着Apollo的字形临帖，后面授权条款变了怎么办？这不像书法，颜柳的字帖不会突然改版权协议。

有个事不知道该不该说，我听说小鹏那边已经在偷偷把Apollo相关的依赖往外拆了，怕的就是这一手。蔚来这步棋，到底是真open还是表面功夫，等ES9上市之后看它的开源合规声明就知道底细了。
哈哈
话说回深圳之后发现，这边搞车的团队真的特别爱聊"自主研发"这四个字，但你们去翻翻他们的package.json，sounds good的没几个敢全晒出来。这潭水，深着呢。

mistyism 你这个制茶的类比挺有意思，不过我想补一个技术角度的观察。

炒茶的火候确实靠手感，但代码这块有个更tricky的问题——license compatibility。就像你祖父揉捻茶叶，力道对了茶就香，但如果你用的茶叶来自不同山头，有些山头规定"只能手炒不能机炒"，有些规定"炒完必须公开配方"，你混在一起炒出来的茶，法律上能不能卖都是个问题。

我去年给一个startup做技术尽调，他们车机系统里引了7个GPL组件、3个Apache 2.0、还有1个SSPL，CTO自己都搞不清楚这些license的传染性边界在哪。最后法务给的建议是：要么重构，要么开源整个中间件层。他们选了重构，工期直接加了三个月。

所以你说的"炒出自己的韵致"，在开源世界里不只是技术问题，还是合规问题。很多团队把GitHub当免费素材库，fork完改改就商用，这跟拿别人家祖传茶谱开店还不标注来源差不多。

不过我倒不觉得ES9会在license上翻车，蔚来法务团队应该比startup强多了。我更好奇的是他们会不会像Tesla那样，把一些非核心模块反哺回社区——毕竟用了Linux和ROS这么多年，按GPL的精神，回馈点patch也算本分。
其实
你读韦应物那句诗，我倒想起另一个角度：开源社区这瓢酒，喝的人多，酿酒的人少。大部分车企是来喝酒的，不是来酿酒的。

random_hk 你那句"黑箱调用"真是说到我心坎里了。在日本打工那会儿，公司有个前辈特别喜欢在代码里塞各种开源库，出了问题就甩锅"upstream的bug"，literally成了他的免责金牌。后来我回国进了一家小厂，发现这毛病更离谱——有回排查一个内存泄漏，追了三天最后发现是某个"自主研发"的调度器直接魔改了FreeRTOS内核，注释都没删干净。

你定那个规矩多花的三成时间，我觉得值回票价。我见过最离谱的是一个团队把Apollo的planning模块整个包进docker，接口层糊层皮就当自研智驾，结果高速上跟丢车道线，log里蹦出来自百度的报错信息。说真的，这种"书奴"连临帖都算不上，顶多算拓片匠。
服了
btw你在红旗Linux上写材料是什么体验？我唯一一次用红旗是大学机房，开机五分钟，wps卡死三次，那大概是我对国产系统最早的PTSD（笑）

random_hk，你提到"黑箱调用"这个点真的戳到我了。我在温哥华这边做兼职的时候，跟过一个很小的startup，老板也是那种"能跑起来就行"的心态，结果有一次一个开源库的license合规没处理好，差点惹上麻烦。从那以后我就特别理解你说的"必须有人能读懂核心逻辑"这条规矩，多花点时间真的值得。嗯嗯

不过你那个"三成时间换九成坑"的说法，我倒是想问问，你们团队后来有没有遇到过那种——代码明明看懂了，但作者的design rationale跟你们场景根本不对付的情况？我前阵子修过一个bug，追到最后发现是上游库对edge case的处理跟我们的数据流假设完全相反，那种"看懂了但用不了"的无力感，比黑箱还折磨人。你们是怎么筛这种的？

random_hk，你提到红旗Linux和深圳外包那段让我想起一个事。

2019年在肯尼亚内罗毕，我们项目组用的就是一台跑CentOS 5的老Dell，当地IT guy叫Moses，他跟我说这机器是从UNHCR那边二手收来的，硬盘坏道多到smartctl报警。但他用Linux跑得飞起，因为"source code is free, man, I just read it and fix what I need"。那台机器管着整个营地的水净化系统数据采集，uptime 400多天。

所以我对你那个"读懂核心逻辑"的规矩特别有共鸣。不是方法论层面的认同，是见过反面教材之后的确认。非洲那边NGO项目里，意大利团队留下的传感器网络，文档全无，依赖一个意大利人自己写的C++库，那人离职之后整个系统变黑箱。简单说我们花了三个月逆向，最后发现核心就是个PID控制循环加了个卡尔曼滤波，300行代码的事，被封装成.so文件当宝贝供着。

简单说回到车机这个话题。你说的"六成"质疑很对，我补充一个维度：dependency graph的深度问题。

Linux kernel本身是GPLv2，这个没问题。但Android Automotive之上，车企通常会加一层middleware，这层东西的license compliance经常是灰色地带。我去年帮一个国内Tier 1供应商做audit，发现他们用的某个音效处理库，表面是Apache 2.0，实际链式依赖了3个GPL组件，法务看到报告脸都绿了。

所以"六成"这个数字，如果算的是direct dependencies，可能还低估了。算transitive的话，八成往上走。关键不是比例，是compliance的颗粒度。蔚来法务团队如果能把这棵树理清楚，那才是真本事。

简单说Apollo那个点你说得也准。2017年开源的时候我在首尔大学实验室跟导师讨论过，他当时就说"百度这是在用开源做技术标准卡位，不是做社区"。后来证明他说对了。简单说ROS的问题更根本——它连实时性保证都没有，硬实时场景下调度延迟不可控，这个不是优化能解决的，是架构层面的取舍。

不过话说回来，车企用开源这件事，我现在的态度比两年前宽容很多。非洲回来之后我对"自主可控"这个词有了新的理解。Moses那台破Dell能跑400天，靠的不是自主可控，是有人愿意读代码、理解代码、在需要的时候改代码。这个能力本身，比代码是不是自己写的更重要。

대박，写太长了。总之你那个"三成时间换九成坑"的trade

笑死，看到"留白"俩字我差点以为你在聊我那辆改了三天三夜还是没改完的泥ocollege

不对，是泥抹不开
真的假的
……算了不挣扎了总之技术这玩意儿吧有时候就得自己踩坑，踩多了才知道哪些该闭哪些该开hh

哈哈，你这“拿狼毫写小楷”的比喻绝了，我笑了半天。说真的，作为纯用户（连代码都敲不利索那种），我倒是特别想从另一个角度聊聊这事儿。

你提到的“六成论”让我想起以前在健身房带课，总有人问我“这个动作能减掉百分之多少的肚子”。我说兄弟，脂肪不是按百分比掉的好吗——你练一个月，腰围小了3厘米，但肚子上的肉可能只薄了五分之一，剩下那五分之四还在呢。所以蔚来那个“六成”，大概率也是宣传口径里的“六成”，跟咱们理解的那个技术分层完全是两码事。

不过说真的，我倒觉得车企闭源核心算法这事儿挺能理解。你想啊，我去年做外贸被客户坑了一回，那套供应商管理系统是我自己熬夜写的，后来对方想让我共享源码，我说你让我共享可以，但得签协议——不是我不厚道，是这系统里掺了我上一家公司三个月的试错经验，还有我半夜跟印度客户吵架悟出来的定价逻辑。这玩意儿就跟私房菜谱似的，公开了佐料单子，但火候和配比分量的秘密，打死也不能说。
笑死
但开源社区的好处在于，它让造车这件事从“必须自己挖井”变成了“可以借水渠”。我上个月看小米SU7的拆解视频，车机底层确实是AOSP那一套，但上层交互做得真挺顺滑。这就像我学英语那会儿，语法书是开源的（新概念英语谁都能买），但你能把口语练到我这个工地搬砖转外贸的水平，靠的还是自己蹲在宿舍对着镜子练的那半年。服了

所以你说ES9这卷行草怎么写——我觉得大概率是：字帖是借来的（Linux/AOSP），砚台是买的（百度Apollo/ROS），但握笔的姿势和落款的力道，得靠自己慢慢磨。至于磨出来是王铎还是书奴，等试驾了再说呗。反正我约了下周四的试驾，到时候回来给你们汇报手感。

看了楼主把开源比作临帖，我倒想从另一个角度聊聊——许可证。

你提到车企闭源是"商海里的自保"，这个判断没错，但自保的方式其实比闭源复杂得多。我前年给一个做车载中间件的团队做技术顾问，他们当时踩了个大坑：用了一个GPLv3的库做底层通信模块，结果被社区发函要求公开衍生代码。最后花了两周把那个模块整个替换成Apache 2.0许可的替代方案，项目延期不说，工程师加班加到怀疑人生。

所以看到你说"六成根基扎在Linux与Android Automotive"，我第一反应不是占比问题（虽然楼上几位追问得很在理），而是这六成代码的许可证兼容性是怎么处理的。Linux内核是GPLv2，Android Automotive里用户空间部分大量用Apache 2.0，这两个许可证的兼容性在法务眼里就是一颗定时炸弹。更别提如果智驾模块真如你所说摹过Apollo——百度Apollo用的是Apache 2.0，但ROS生态里各种许可证都有，BSD、MIT、GPL、LGPL混在一起，法务审一个模块的依赖树能审出一身冷汗。

我那个客户最后搞了个内部合规工具，每次CI/CD跑完自动扫描依赖库的LICENSE文件，发现GPL系的就标红，需要法务和架构师双重签字才能用。这玩意儿后来还卖给了一家新势力车企，据说他们法务部因为这个工具少招了三个人。

说回ES9。蔚来敢公开提六成开源根基，说明他们的法务和架构团队已经把许可证合规这件事做透了。这比技术选型本身更值得关注——技术选型是工程师的事，许可证合规是组织能力的事。后者才是车企能不能持续从开源社区汲取养分的底层保障。

临帖容易，但临帖用的墨不能是偷来的，纸不能是抢来的。开源社区的"帖"是免费给你看，但怎么用、用到什么程度、用了之后要承担什么义务，这些规矩比书法的笔法复杂多了。

楼主这个"砚田耕耘"的比喻让我突然想到，在韩国的时候参加过一个小型黑客松，有个学长用ROS改了个送餐机器人的导航，代码写得乱七八糟，但演示那天所有人都鼓掌了。后来他把改进版真的开源了，现在好像有三百多个star。

那时候我刚到首尔不久，韩语还说不利索，在角落里啃着炸鸡看他调试，觉得开源社区最温暖的地方不是代码多厉害，而是陌生人愿意把自己踩过的坑标出来给别人看。就像楼主说的"铺平门槛"吧，这个我感受很深。会好的

不过我也同意vintage2003说的，"六成"到底怎么算确实要打个问号。我在学校做项目的时候也遇到过，为了应付检查把依赖库全算进去，其实真正自己写的没多少。但反过来说，完全从零开始造轮子也不现实， especially 在车机这种复杂系统里。

我更好奇的是，如果ES9真的在核心算法上做了突破，蔚来愿不愿意把那一部分也放出来呢？哪怕只是一点点边角料，对行业都是很大的鼓励。毕竟疫情被困在国外那半年，我全靠开源项目活着，深知那种"原来我不是一个人"的感觉。

希望ES9不只是用开源来打底，也能真正回馈这个江湖吧。대박，期待试驾报告！