Google 调整 Android 开源政策，核心开发全面转向私有分支，这将对行业产生什么影响？

AOSP的master/main分支毫无意义，AOSP很早就是这样了，或者说一直就是如此，任何试图下载或者编译其主分支代码的人不出半个小时就能得出这个结论。

观察AOSP的代码历史就可以发现，一些仓库的主分支已经无法作为开发分支/优先提交的分支了。

以Bionic libc仓库为例

• 主分支commit几乎全部为merge其他分支的commit，然而虽说是merge，但更接近于cherry-pick。
• 几乎所有commit都要解决合并冲突。
• 需要很多轮的merge/revert/reland/revert reland/reland^2

一个小功能要半个月才能合并，即使都是Google员工，效率低成这样，显然是无法继续维持了。一个月提交20行代码，这绩效怎么算呢。

此外，AOSP不是monorepo，而是用的repo工具管理的上百个仓库。repo工具需要manifest仓库定义各个子仓库的分支或者tag，然后才能checkout一套源码出来。

但是，或许由于管理的问题，或许由于授权的问题，AOSP从来不公开未发版版本的manifest，也就是说，正在beta测试的系统，只有Google和GMS合作伙伴能拿到源代码，而其他没有权限的开发者，只能看到主分支上残缺的代码，以及处于GPL要求必须开源的代码。

如下图所示，只有发版的android 15有能用的分支，android 15 beta时期和现在的android 16 beta的分支都带着gpl的标记，里面也没有完整的AOSP系统

但是这并非什么秘密，10年前就是如此，只是10年前国内的安卓厂商根本不参加beta计划（好像Android 8之后Google才联合国内厂商推出beta系统），不在beta期间推出Android beta系统，对Android大版本更新也不上心。而lineageos等第三方基于AOSP开发的类原生系统也是在Google官方系统更新几周后才能等到AOSP发布的开源分支，然后进行二次开发。

即使是发版的分支，Google的功能更新（比如最近Android的QPR更新）或者安全更新，也是提前发布给GMS合作伙伴，然后才会公开。非GMS合作伙伴晚至少一个月才能从AOSP看到安全更新，这对于商业用途是完全不可接受的。

更令人疑惑的是，任何一个AOSP的分支，其代码仓库的历史都是几乎不可读的，各个分支之间也没有什么依赖关系。机器人自动的merge/cherry-pick导致AOSP的历史不像典型git仓库的树状历史，而是更接近一种织物，一个commit在各个分支之间串来串去。

在这种情况下，不开放主分支，甚至于不保留commit历史都无所谓了，反正AOSP的commit历史已经接近于不可读了。

这样的软件，自然仍算是开源软件，因为协议是Apache 2.0，是开源协议。

我建议大家都阅读一下《大教堂与市集》（The Cathedral and the Bazaar）这本小册子，简单来说，这本书讨论了两张开源软件的开发模式

• 教堂模型。定期发布新版本并放出源代码，但版本之间的代码只有一组专门的开发人员可以获得。早期的GNU Emacs和GCC都是这样开发的。
• 集市模型。代码总是在互联网上可以获得，且公众可以参与开发。Linux内核是以这样的模式开发的。

这本书直接推动了网景开源其浏览器并启动Mozilla项目，而绝大多数人熟悉的开源项目实际上都是以Mozilla的模式开发的，因为不可能像Linux内核一样几乎没有公司主导，且完全去中心化，只以Maintainer作为管理者；也很难采用教堂模型这种在大家看来极不透明的方式进行。但尽管如此，教堂模型仍属于开源软件，只是大家可能不信任这样的模式了。

当然这些问题都是AOSP这个项目自己的管理问题，其他开源项目并没有这样的问题。我们可以看一下其他的巨型开源项目（代码量大于5千万行）的状况。

这是Google Chrome，目前最新版是M134

这是我在Gentoo Linux上的chromium，同样的M134

这个Chromium运行在musl libc之上，是Google不支持的平台。但是我可以移植到该平台，这就是开源的意义。

Chromium也会tag测试版(beta, 目前是M135)和开发版(dev, 目前是M136）

checkout任何一个tag，都可以编译出该版本的浏览器，包括beta和dev版。

以Chromium的下游Electron为例，Electron 35使用M134，但已经可以更新到Chrome没有发版的134.0.6998.179补丁版本，而Electron 36已经可以使用仍处于dev通道的M136版本。Electron的测试版也会定期发版，并通过GitHub release或者npm直接下载使用。

Firefox从2011年开始学习Chromium的发版策略，快速飙版本号，不过由于MPL属于CopyLeft协议，定制Firefox的产品并不多，Thunderbird、Tor浏览器属于少数这样的产品。但Mozilla计划20多年以来，都是一小波被雇佣的开发者专职开发，外加工作可以使用Bugzilla等设施贡献代码。

再看Webkit，他们只给正式版打tag，比如620.2.4是Safari 18.3对应的版本，但任何分支都可以编译，并在macOS或者iOS模拟器上让Safari运行自己编译的内核。此外webkit-gtk也为Linux桌面提供支持。

然后看OpenHarmony，正式版是5.0.3.135

这个版本是3月20日推送的

对应的tag要更早，在2月26日

OpenHarmony 5.0.3系列的下一个版本很有可能是5.1.0系列，目前最新版是5.1.0.101

OpenHarmony会定期给各个分支增加版本号，大家可以提前通过OpenHarmony的代码了解到未来的功能，以及开发计划，例如鸿蒙PC版的功能。