部分同意

@布丁

的观点，大公司都应该对自己的代码负责，不应该引入不必要的依赖。bazel 是大公司应该使用的解决方案。

在我看来，Go 的本质是简单：开箱即用，稳定可靠。用 20% 的功能，解决 80% 的问题，生产力极高。而当前包管理器的混杂，已经让 Go 变得越来越麻烦了。不管是不是喜欢， Go 都必须官方解决这个问题。

Go 从 Google 走出来，内部使用 blaze 系统，所以项目的源代码公用一个 repo, 任何修改都要跑 test 保证整个 repo 不出问题，对应的开源的方案就是一个 $GOPATH 走天下，并没有关心依赖问题。但开源社区是无穷多个小 repo 的合集，像之前 go get 直接拉个最新的 master 版本，显然带来了隐患：依赖一更新，已有代码就可能编译不过了。

因此之前社区自发形成了各式各样的包管理工具：

https://docs.google.com/document/d/19HNnqMsETTdwwQd0I0zq2rg1IrJtaoFEA1B1OpJGNUg/edit

，大部分工具都解决了差不多的问题，只是使用上有些许的区别。这些眼花缭乱工具，对选择困难症来说，不是什么好事情。

这次要出官方的包管理，还是为了增加社区的凝聚力，保持 Go 开箱即用的简单特性。经过充分的调研，做一个能让大部分用户满意的管理器，让大家重新 focus 在生产力上。

有兴趣的，可以看看相关的设计文档，如果没有 cover 到自己的 case 可以去讨论。依然加一句，大项目还是要走 bazel 这种方案，把依赖在公司层面解决，而不是每个小项目单独维护。

Stories:

https://docs.google.com/document/d/1wT8e8wBHMrSRHY4UF_60GCgyWGqvYye4THvaDARPySs/edit

Features:

https://docs.google.com/document/d/1JNP6DgSK-c6KqveIhQk-n_HAw3hsZkL-okoleM43NgA/edit

Design space issues

https://docs.google.com/document/d/1TpQlQYovCoX9FkpgsoxzdvZplghudHAiQOame30A-v8/edit