大家好，我是煎鱼。
前两天有读者提醒我关注 Go 大当家 Russ Cox 发起的 Go 工具链中的遥测（telemetry in the Go toolchain[1]）讨论。不看不知道，一看下一跳。
今天来分享一些看法和信息。
为什么要收集数据
Russ Cox（下称 rsc）发起的背景是 Go 开源项目的开发者（例如：Go 核心团队）在没有遥测的情况下，会遇到如下的场景：
- 需要依赖外部的错误报告（例如：GitHub issues）来了解他们自己写的软件如何在意料之外发生异常。
- 调研用户是如何使用自己写的开源项目，是否符合预期，又或是创造出了新的用法。
这么一听，好像和我们平时的认知也差不多。换位思考一下，Go 核心开发者就比较头疼了。认为这两种方式作用都很有限，达不到他们想要的效果。
因此想要抽样收集用户的使用数据，便于 Go 团队更好的开发和调研。
被局限的例子
错误报告
我们会提交错误报告，一般只会出现在类似 ”我们预期这事应该能正常跑起来，但你居然没有跑起来“ 的场景下。在现有的情况下，如果程序在不影响正确性的情况下出现了错误行为，用户就不可能注意到。
反之，如果实施了遥测（收集数据），开发者就可以通过 Go 工具链收集上来的统计数据发现异常。（有抓手了）
具体案例，rsc 说明了在 Go 1.14 版本的发布中，对 macOS Go 发行版的构建方式进行了更改，造成使用 net 包（使用 cgo ）编译任何程序都需要安装 Xcode。
这不是他们所预期的，是意外之外的。
但在发生这问题的三年内，没有任何人报告过这个错误。用户只是简单地接受了这是必要的安装。
直至近期，Go 核心团队排查其他问题，才发现有这个坑。如果有遥测收集使用数据，那这个问题完全可以被避免。
调查用户
Go 开发团队想知道 ”用户想用 Go 做什么“，或是想基于数据用于做一些新老功能版本的决策。
但现在开源项目普遍都很难，他们只能发调查报告，就像我们每年填的 Go 开发者调查报告，就是这个目的。
Go Developer Survey 2022 Q2 Results
但是 rsc 对调查报告也是不满足的。因为只是一个小样本，效果有限。且需要大量的用户选项和回复才能得到相对准确的测量结果，比较浪费时间。
具体案例，rsc 举例 go 开源项目，经常会在新版本增加开关，再逐步去掉的做法。像最近宣布 Go 1.21 起将不再支持 macOS1.13/1.14，马上就收到了用户的反馈，要求保留。
如果有遥测收集使用数据，这个问题将有具体的数据作为决策支撑。就跟我们平时前端同学，会收集用户端的操作系统和版本作为是否支持 IE 的依据等。
想收集什么数据
说要收集，会在哪收集，具体要收集什么呢？会收集的地方主要是 Go 工具链，例如：Go 命令、Go 编译器、Gopls 等地方。
收集的数据，将至少包含工具链的基本信息，例如：
- Go 工具链版本。
- 是什么操作系统和架构构建的。
- 主机操作系统版本（例如：Windows8）。
- Go 工具链使用的其他工具的粗略信息，例如本地 C 编译器（例如：gcc 2.95）。
不会包含任何形式的身份信息，例如：
- 没有用户登录。
- 没有机器 ID。
- 没有 MAC 地址。
- 没有 IP 地址，没有 IP 地址前缀。
- 没有地理位置信息
- 没有随机生成的伪 ID，没有其他种类的标识符。
收集的数据会在 Go 网站上公布，定时展示统计图表等，便于所有 Go 开发者审阅和查看。
社区争议满满
绝大部分开发者是没有直接同意 rsc 这么干的，主流的回复分成了三派。
大致如下：
- 直接拒绝，觉得这是在侵犯个人隐私。
- 建议做成可选项，例如：限时选择上报、选择上报（使用 Go 时弹出 Cookie 弹窗、抛出异常时弹出弹窗）等。
- 直接抵制，认为 Go 重蹈 Google 后路。用词强烈，要求 rsc 公开道歉，表示这是推下悬崖的选择，降低了信任。
整体来看，参与讨论的 Go 开发者都非常关注 ”隐私“ 的问题。更建议做成可选项，也就是用户选择上报。
如果以后写 Go 的时候弹出 Cookie 弹窗还是很 ”有趣“的吧（doge。
总结
Go 核心团队本身的出发点是好的，他们在维护 Go 开源项目时，经常拿不到一些关键数据和信息，导致在做决策时很纠结。
这在业务应用中，比较常见的是在前端埋探针，获取你的客户端信息等。但这是闭源的，整体风险没有那么大。
但对于开源项目来讲，这是开源的，受到所有人的检阅。这类隐私数据收集，在台面上直接默认上报肯定是不可行的，争议会比较大。
从结果来看，由于没有更多新的内容，比较情绪化，这个讨论已经被中止。未来如果做，我猜更大概率是做成可选项，询问式。
