开源项目被大厂收购后的结局，你的依赖库还在吗

开源项目被大厂收购后的结局，你的依赖库还在吗

从 Square 的 LeakCanary 说起

Square 这家公司对 Android 生态的贡献，老一点的开发者应该都有印象。Retrofit、OkHttp、Picasso、LeakCanary，几乎构成了 2015-2018 年间 Android 开发的基础设施。但 Square 的技术影响力衰退得比想象中快，不是因为它做错了什么，而是因为它把东西做出来之后，大厂们用另一种方式完成了"接管"。

LeakCanary 2.0 的发布过程很有意思。Pierre-Yves Ricau 在 Square 内部推动重写，从基于 RefWatcher 的侵入式方案转向 Shark 这个独立的堆分析引擎。这个技术决策本身很干净，但紧接着 Square 就把 LeakCanary 的核心维护者推到了风口浪尖——项目还在，公司还在，可 Square 对 Android 开源的投入明显收缩了。Pierre-Yves 后来去了什么公司？Block（前 Square）的加密货币部门。LeakCanary 的提交记录从每周数次变成数月一次，最后干脆进入"社区维护"模式。

这种模式听起来体面，实际上是慢性死亡。Android 14 对后台执行的限制收紧之后，LeakCanary 的 heap dump 触发机制在部分 OEM 设备上直接失效，Issues 区堆了上百条反馈，维护者能给的回复只有"等社区 PR"。一个曾经每个 Android 开发者都引用的库，现在在新项目里的采用率肉眼可见地下滑。不是因为它技术过时，而是因为它的维护结构被原公司的战略调整掏空了。

Square 没有"收购"LeakCanary，因为它本来就在 Square 内部诞生。但这个故事的模板后来被复制了无数次：大厂先把人招进去，让项目在公司品牌下运转几年，等公司战略转向，项目就变成无主的孤儿。

Firebase 的"善意"接管

Google 对开源项目的吸收策略更隐蔽，也更难反抗。2014 年 Firebase 被收购的时候，它还只是个实时数据库服务。后来的故事大家都熟悉，Firebase 膨胀成 Google 的"移动开发全家桶"，而它的扩张很大程度上是通过吞并独立工具完成的。

Fabric 的 Crashlytics 是最典型的案例。2017 年 Google 从 Twitter 手里买下 Fabric，承诺"Crashlytics 会继续作为独立产品存在"。这个承诺的保质期大约是 18 个月。2019 年 Fabric 控制台关闭，所有用户强制迁移到 Firebase Console。迁移过程里的技术摩擦被有意无意地忽略了——旧版 Fabric SDK 的初始化逻辑和 Firebase SDK 的依赖注入体系完全不兼容，很多项目为了迁移不得不重构整个 Application 层的启动顺序。

更麻烦的是数据归属。Fabric 时代 crash 报告的历史数据在迁移后被"部分保留"，部分是多部分？Google 从来没给过明确说法。我实际处理过的一个项目，2016-2018 年的 Native Crash 符号表在 Firebase 控制台里直接消失，找支持工单来回扯皮两个月，最后得到的标准回复是"建议参考当前版本的文档"。

Crashlytics 的技术内核其实没变多少，还是那个基于 PLCrashReporter 的符号化流水线。但当你把它从独立的 Fabric 控制台塞进 Firebase 的统一界面里，它的使用体验、数据可访问性、故障响应速度都发生了质变。这种"收购后退化"不是技术问题，是产品政治问题。Google 需要 Firebase 的 DAU 数字好看，至于老用户的迁移成本，那是用户自己的事。

JetBrains 的 Kotlin 和 Compose Multiplatform 的暧昧处境

JetBrains 的情况更复杂，因为它既是工具厂商，又是语言标准制定者，同时还在推自己的跨平台框架。Kotlin 1.0 发布的时候，Google 还没官宣支持，很多团队是在"未来可能官方支持"的预期下提前押注的。2017 年 Google I/O 宣布 Kotlin 为 Android 一级语言，这个决策的公关叙事是"Google 倾听社区"，但技术权力的实际转移被淡化了。

Kotlin 的语法演进控制权在 JetBrains 手里，但 Android 平台的实现细节——比如 Kotlin 编译到 ART 字节码的性能特征、协程在 Android 主线程调度器上的行为——越来越受 Google 的约束。Kotlin 1.5 引入的 JvmInline value class 在 Android 上的实际效果，和 JVM 服务端的表现差异很大，因为 ART 的 inline 优化策略和 HotSpot 完全不同。这些问题 JetBrains 不会优先处理，Google 也没有动力深入，最后卡在中间的永远是开发者。

Compose Multiplatform 的处境更能说明问题。JetBrains 把它推出来作为"跨平台 UI 框架"，但 Compose 的核心 runtime 和编译器插件代码库在 Google 的 AndroidX 仓库里。JetBrains 能做的是在 Google 的发布周期之外，额外维护 Desktop 和 iOS 的 target。这个架构决定了 Compose Multiplatform 的稳定性永远比 Android 原生 Compose 慢半拍。2023 年 Compose 1.5 发布的时候，Android 版本的 Material3 组件已经相当完整，Desktop 版本的窗口管理和输入法集成还有明显的 bug，Issues 区有人直接问"Desktop 是不是二等公民"，JetBrains 员工的回复很诚实："资源优先级不同"。

这不是批评 JetBrains，而是指出一个结构性的依赖陷阱。当你的跨平台框架本质上是大厂平台框架的"外围补丁"，你的技术自主性就是有限的。JetBrains 比大多数公司更有底气，因为它有付费 IDE 的收入基本盘。但如果你是纯粹的开源项目，被大厂"合作"之后的技术地位只会更脆弱。

Square 到 Block，OkHttp 的专利暗雷

回到 Square 的遗产，OkHttp 的故事比 LeakCanary 更耐人寻味。OkHttp 4.x 用 Kotlin 重写的时候，社区里有不小的争议。Java 开发者抱怨被迫引入 Kotlin 标准库依赖，包体积增加几百 KB。Square 的回应是"Kotlin 是 Android 的未来"，这个判断本身没错，但时机选择很微妙——正好在 Square 全面转向 Kotlin 技术栈、同时准备把公司品牌改为 Block 的节点上。

更深层的问题在许可证。OkHttp 一直用 Apache 2.0，这本身没问题。但 2022 年有人翻出了 Square 在 2015 年申请的一项专利，涉及 HTTP/2 连接复用的特定实现方式。这个专利从未被主张过，但它在法律上的存在意味着，如果某天 Block 的战略需要，它有一个潜在的法律工具。开源社区对"专利承诺"的信任很大程度上建立在公司的善意上，而公司架构变更（Square 到 Block）之后，原来的善意承诺由谁继承、是否仍然有效，从来没有人给出过书面确认。

OkHttp 的维护现在基本交给 Jesse Wilson 个人和少数外部贡献者。Jesse 的技术能力毋庸置疑，但他已经不在 Square/Block 全职工作。一个被无数金融级应用依赖的网络库，核心维护者是个人志愿者，这个现实和 OkHttp 在 Maven Central 上的下载量数字放在一起看，有一种荒诞感。

被收购即冻结：JCenter 和 Bintray 的死亡预告

JFrog 的 Bintray 和 JCenter shutdown 是 2021 年的事，但余波到现在还没消完。JFrog 不是被传统意义上的"大厂"收购，它自己就是上市公司。但 JCenter 作为 Android 生态事实上的默认仓库，它的关闭方式暴露了大厂/平台方对基础设施的漠视。

Google 在 Android Gradle Plugin 7.0 里把默认仓库从 JCenter 切到 Maven Central，这个技术决策本身合理。但 JCenter 的"只读模式"承诺很快被打脸——2022 年有多个库的发现 JCenter 上的旧版本 artifact 被 404，JFrog 的解释是"存储优化"。对于那些版本号写死在 build.gradle 里、几年没更新的遗留项目，这意味着构建直接中断。

更隐蔽的伤害在 transitive dependency。很多库只在 JCenter 发布，它们的依赖树里某个深层节点指向另一个只在 JCenter 存在的库。JCenter 关闭后，这些依赖关系变成无法解析的幽灵。我遇到过最离谱的情况是一个 2018 年的图像处理库，它依赖的某个 Native 库 .so 打包工具只在 JCenter 有 release，Maven Central 上只有源码没有预编译 artifact。最后解决方案是 fork 整个工具链自己编译，成本远超当初引入这个库时节省的开发时间。

Google 对这件事的公开态度是什么？Android Studio 的迁移向导里加了几行提示，建议开发者"检查依赖来源"。没有补偿机制，没有针对旧项目的兼容性方案，因为 Google 不从这些库的存活中直接获利，也就没有动力投入资源。

微软的 GitHub 和 npm 收购，Android 生态的间接阴影

微软收购 GitHub 的时候，Android 开发者普遍觉得"不关我事"。但 GitHub 作为开源协作基础设施，它的产品决策会影响所有托管其上的项目。GitHub Copilot 的训练数据包含大量开源代码，这个争议在 2022 年爆发的时候，很多 Android 库的维护者才发现自己从来没认真读过 GitHub Terms of Service 的更新条款。

更实际的影响在 GitHub Actions 的免费额度政策。Android 项目的 CI 构建因为需要模拟器镜像和 NDK 工具链，耗时普遍比纯 Java/Kotlin 项目长。GitHub Actions 的 macOS runner 从免费到限流再到收费的过程，直接推高了很多 Android 开源项目的维护成本。那些没有商业赞助的个人项目，要么接受更慢的反馈周期，要么把 CI 迁出 GitHub，而后者意味着离开最大的开发者流量入口。

微软对 npm 的收购是另一条线。npm 和 Android 没有直接关系，但 JavaScript 工具链在 React Native、Flutter Web 等跨平台方案里的渗透，让 npm 的政策变化间接波及 Android 构建。npm 的 audit 安全扫描在 2021 年大规模误报之后，很多 React Native 项目的 CI 流水线被迫关掉安全检查，这个技术债务最后会在生产环境的依赖版本管理里体现出来。

个人维护者的退出与项目的"社会性死亡"

大厂收购开源项目，最极端的形式不是买项目，是买人。项目本身留在 GitHub 上，Apache 许可证还在，但核心维护者去了大厂做内部工具，公开版本的更新频率从每月降到每年，最后变成零。

Fresco 是 Facebook 的图片加载库，曾经是 Android 上唯一认真处理渐进式 JPEG 和 WebP 动画的选项。2018 年之后 Fresco 的更新明显放缓，Facebook 的公开说法是"内部需求稳定，社区驱动维护"。实际上 Fresco 的核心团队被调去支持 Instagram 的视频基础设施，公开版本只接收安全修复。到 2022 年，Fresco 的 GitHub 仓库里 open issue 超过 500 个，很多是关于 Android 12 以上版本的通知栏图片显示问题，没有人处理。

这种"社会性死亡"比正式弃用更糟。正式弃用至少给你一个明确的迁移信号，Fresco 的状态是"还能用，但新系统版本上的 bug 没人修，你也找不到替代品因为迁移成本太高"。很多项目就这样卡在半死不活的状态，成为技术债务的一部分。

Glide 的情况稍好，因为它有 Google 背景的维护者（Sam J 在 Google 工作），但 Glide 的更新节奏同样受 Google 内部优先级影响。Glide 4.14 到 4.15 之间隔了 14 个月，这个周期里 Android 13 发布了，PhotoPicker API 改了，Glide 的默认集成方式却没有同步更新。不是技术做不到，是维护者的注意力被其他事情占据了。

依赖库的健康度，到底该怎么看

说了这么多负面案例，不是为了制造焦虑，而是想指出一个评估框架的问题。我们选依赖库的时候，习惯性地看 GitHub stars、看最近提交时间、看版本号数字，这些指标在大厂收购之后会变得高度误导。

一个被大厂收购的项目，GitHub stars 不会掉，甚至可能继续涨，因为大厂的营销机器会把它推给更多开发者。最近提交时间可以通过自动化依赖升级机器人来维持表面活跃。版本号可以不断 bump，即使没什么实质变化。

真正该看的指标是什么？我觉得有几个：

维护者是否还在原公司，以及原公司是否还把项目放在战略优先级里。这个信息不会写在 README 上，需要你去翻 commit 的 author email 域名变化，去看核心维护者的 LinkedIn 动态，去搜他们在 conference 上的演讲主题有没有偏移。

项目的 issue 响应模式。是个人维护者在周末回复，还是公司有专职的 developer relations 团队在工作时间处理？后者听起来更好，但专职团队的存在往往意味着项目已经被"产品化"，而产品化的下一步通常是平台绑定或功能冻结。

许可证的专利条款和贡献者协议。Apache 2.0 的专利授权是互惠的，但有些公司会在自己的 fork 上附加额外条款。Google 的 AndroidX 库用 Apache 2.0，但提交 PR 需要签署 Google CLA，这个 CLA 里有专利授权的隐性承诺，但措辞和纯 Apache 2.0 不完全一致。这些细节在项目健康的时候无关紧要，在出现法律纠纷时可能成为争议点。

一个具体的决策困境

我去年参与的一个项目，技术选型时需要在 Coil 和 Glide 之间做选择。Coil 是 Coil 团队的 Kotlin-first 方案，基于 Kotlin Coroutine 和 OkHttp；Glide 是老牌选择，Google 背景，生态成熟。

表面看 Coil 更"现代"，但深挖下去，Coil 的核心维护者 Colin White 在 2023 年加入了 Shopify。Shopify 有自己的移动技术栈，Colin 的个人 GitHub 上 Coil 的提交频率没有明显下降，但 Coil 的路线图文档里，"3.0 版本"的计划从 2022 年拖到现在，中间只发布了几个 alpha。Shopify 没有公开承诺对 Coil 的投入，Colin 的雇佣关系意味着他的技术注意力至少有一部分被 Shopify 的内部需求牵引。

Glide 这边，Sam J 确实还在 Google，但 Glide 的 issue 区同样有大量未响应的反馈。Google 内部对图片加载的需求可能更多通过 Compose 的 AsyncImage 和自定义解决方案满足，Glide 的"官方背景"不等于持续进化。

最后我们选了 Coil，不是因为确信它更健康，而是因为它的代码结构更干净，fork 维护的成本相对可控。这个决策本身就是在赌"如果哪天官方维护停滞，我们能不能自己扛"。这不是理想状态，但在当前的开源生态里，这可能是唯一务实的评估方式。

大厂的开源战略，从来不是做慈善

最后想直接说一个很多人心里明白但公开讨论时回避的观点：大厂对开源项目的投入，计算的是生态控制权和人才招聘漏斗，不是代码本身的公共价值。

Google 推 Kotlin，是因为 Java 的许可证纠纷和 Oracle 的诉讼风险。微软买 GitHub，是为了 Azure 的开发者入口。Facebook 开源 React Native，是为了降低移动端的人力成本同时保持 Web 技术栈的连续性。这些动机本身无可指摘，商业公司本来就要追求商业利益。

但开发者如果假装这些动机不存在，用"社区贡献""技术理想"的叙事来理解大厂行为，就会在依赖选择上做出错误的长期判断。你的项目引用了某个大厂背书的开源库，不等于你和这个大厂建立了互惠关系。大厂可以在任何时候调整优先级，而你没有追索权。

Android 生态的特殊性在于，Google 既是平台所有者，又是最大的开源工具提供者之一。这种双重身份让"依赖库健康度"的判断更加困难。Jetpack 库的官方属性意味着它们不太可能突然消失，但它们的演进方向完全由 Google 的平台战略决定。Navigation Component 的设计明显服务于 Single Activity 架构和深层链接的 SEO 需求，这个技术路线是否适合你的应用结构，需要你自己判断，而不是因为"它是官方推荐"就无条件接受。

结尾

开源项目的收购和整合，在 Android 生态里已经发生了太多次，以至于我们几乎把它当成了自然现象。但自然现象不需要你做决策，技术选择需要。

你的 build.gradle 里那些 implementation 行，每一条都是一个信任投票。投票的时候看清楚：你信任的是代码本身，是维护者的个人声誉，还是背后公司的品牌光环？这三样东西的保质期完全不同。

下一个可能被"战略调整"的库会是什么？也许是某个现在看起来很稳固的 Jetpack 组件，也许是某个明星工程师的个人项目。没有预警机制，只有你自己的持续审视。

你的依赖库还在吗？明天还在吗？这个问题没有标准答案，但应该被持续问下去。