OpenHarmony.NET 停更事件复盘和思考
布布的处境
布布有正职工作,是一家游戏公司的技术人员。他说“不需要冒险”,结合他的全职身份,可以理解为他需要在现有工作与外部合作之间做权衡。他想用技术换回报,但前提是不影响现有工作。
五、一条被忽略的主线
布布的公告把矛头全部指向华为,但一个基本事实是:华为和布布之间没有任何直接关系。和华为谈判的是 Avalonia,不是布布,布布是通过 Avalonia 这个中间人才“进入”这个局的。华为可能根本不知道布布这个人——它只知道 Avalonia 有技术方案。
.NET 在国内有大量开发者和真实商业业务、工业经验。当 Avalonia 和华为谈不拢,华为/开源鸿蒙启动招标,这不是“绕过布布”,而是“合作方没谈成,换条路走”。布布最大的认知偏差,是他把自己和 Avalonia 绑定了,以为他们是“我们”。但在 Avalonia 的商业版图里,他只是谈判时用来证明技术能力的筹码——可替代、可抛弃。他把对 Avalonia 的信任,错当成了华为对他的承诺:Avalonia 说“合作达成后雇佣你”,他理解成“华为要雇佣我”。当华为转向外包,他感到被背叛——但华为从未向他承诺过任何东西。
六、Avalonia 的角色
Avalonia 是一家爱沙尼亚商业公司,想进入中国市场,布布的技术方案是它谈判时的“样品”。承诺是口头的,谈判僵持后,Avalonia 没有补偿布布,也没有公开表态。这是一次低成本试错:成功获利,失败也无损失。
七、谈判为什么僵持?
- 身份问题:Avalonia 注册在爱沙尼亚,把鸿蒙生态的适配交给一家敏感区域的外国公司,供应链风险太高。
- 诉求错位:Avalonia 想要的是生态占位——被鸿蒙官方认可、支持,形成长期绑定;而华为/基金会的是工程外包——把适配作为一项具体任务,通过招标交给供应商完成,按项目交付结算。
- 控制问题:华为不能让任何单一供应商锁定关键组件,必须准备备选方案。
- 背调问题:所有正规商业合作都有背调。Avalonia 能否通过华为的供应商审核,本身就是一道门槛;反过来,布布是否对 Avalonia 做过背景调查。
从商业和合规角度,华为/开放鸿蒙很难按 Avalonia 期望的方式合作。
八、更大的棋盘
布布可能没有意识到,他的项目从一开始就被放在一个更大的框架里评估。在中美科技战、技术自主的大环境下,任何一个有战略意义的生态,都不可能把关键节点交给一个不受控的外部实体或个人。鸿蒙作为国产操作系统的标杆,供应链安全、合规审查、技术自主,都是红线级别的要求。
Avalonia 是一家爱沙尼亚公司,在如今这个大环境下,这个身份本身就是高风险。布布闭源想要制造独家性,在这个大环境里反而成了“不可控”的证据。如果一个关键适配层只有一个人能维护,且这个人不是华为员工、没有签任何协议、不受任何约束,那对华为来说,这是风险,不是筹码。这就是招标被启动、外包公司被引入的原因。不是针对布布,而是所有的技术引入,都必须被装进“自主可控”这个框里。布布没有意识到自己装不进去,他以为这是技术问题,实际上这是商业和安全的叠加。
九、认知错位
布布可能没有想明白一个问题:对于鸿蒙生态来说,Avalonia 只是一个选项,不是必需品。事实上,鸿蒙生态正在积极拥抱多种跨平台框架。2025年9月的OpenHarmony佛罗伦萨技术大会上,展示了React Native、Qt、Kotlin Multiplatform、Tauri等多个主流框架适配OpenHarmony的进展。2026年5月的巴黎技术论坛上,专门演示了Rust语言框架Makepad+Robius在OpenHarmony上的开发。除此之外,Flutter、Cordova、uni-app、Electron等框架也都有专门的鸿蒙适配版本,甚至MAUI也可以通过Avalonia后端运行在鸿蒙上。
Avalonia 只是众多选择中的一个。鸿蒙不是因为你做.NET才需要你,而是因为它需要生态,而你恰好能做其中一小块。今天你做了,很好;明天你不做了,只要生态有需求,自然会有别人来做。其他框架的团队也会来做,其他语言的开发者也会来参与。
但布布的整个策略——闭源、等待、拒绝外包——都建立在一个默认前提上:我是唯一
更多推荐



所有评论(0)