在 Twitter 上面看到这样的一个问题：
有很多人讨论 Go 的泛型，为什么我们不能有一个类似于 Java OpenJDK 那样的东西，比如叫作 OpenGo，社区成员可以自己实现泛型，而不是一直等待官方推出泛型。
对于这个问题，有很多人作了回答，但有一个真实的声音没有被直接表达出来，那就是：Go 是谷歌的编程语言，而不是社区的。
当然，很多社区成员为 Go 语言贡献了很多重要并且有价值的东西，这些从贡献者和提交者的多样性就可以看出来。但谷歌作为整个 Go 社区的守门人，它独自决定什么东西可以被 Go 语言接受，什么不能被接受。即使社区有一套流程来决定什么东西可以被加入到 Go 语言中，但不要忘了房间里还有一头八百磅重的大猩猩。只要是谷歌反对的东西，没有人可以让它们加入到 Go 语言中。同样的，如果谷歌决定要把什么东西加入到 Go 语言中，那是势在必行的。
最为明显的一个例子就是在 Go 语言模块系统上发生的一件事情，谷歌 Go 语言核心团队的一名成员放弃了由外部 Go 社区开发的一个模块系统，因为它使用了另一种不同的模型。
可以通过这里查看相关的历史：
https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html
简单来说，Go 语言拥有一个贡献者社区，但是它并不是一个社区项目，而是谷歌的一个项目。无论你认为这是好事还是坏事，它都是一个不争的事实，我们需要接受这个事实。如果你认为有一些重要的东西可以加入到 Go 语言中，那么说服 Go 语言核心团队比努力在社区中达成共识来得更有效。
贡献者将大量的时间和精力投入到社区当中，但如果 Go 语言核心团队不买账，就是在浪费时间。最好的结果也不过是让 Go 语言核心团队对这些问题了解得更深入。
一般来说，社区的声音对于 Go 语言的发展来说并不是十分重要，而我们这些谷歌墙外人，只要接受这样的事实就对了。如果足够幸运的话，我们想要的东西正好与谷歌想要的东西契合，谷歌和 Go 语言核心开发团队就会更加关注这些东西，并及时进行相关的工作。好在谷歌和 Go 语言核心团队也比较关心 Go 语言在业界成功与否，所以他们愿意付出代价解决痛点。
不管怎样，Go 语言表现得挺好，它有一个不大的核心团队，这个团队对于这门编程语言有着良好的品味和愿景，但他们听不进外界的声音，缓慢前行，不太愿意拥抱变化。
我喜欢 Go 语言已经有一段时间了，对 Go 语言的演变和 Go 语言核心团队的管理能力基本上感到满意。我认为慢一点推出泛型功能并不是件坏事，但 Go 语言模块系统事件却给我留下了不好的印象，我似乎有点后悔成为 Go 语言贡献者的一员，哪怕只是一些小的改动我也并不乐意（换句话说，我不想成为“二等公民”）。如果发现 bug，我会继续提交 bug 报告，但也仅限于此。
Go 语言的团队声称他们比较关心整个社区，并且希望更多的人参与进来，这种论调让我感觉很可笑。我不否认他们关心社区，但只关心某些特定的方面。我觉得 Go 语言团队与其暗中做小动作，不如坦诚布公地面对这种状况。
谷歌和 Go 语言核心团队
你可能会问，Go 语言到底是谷歌的还是 Go 语言核心团队的。虽然说 Go 语言的一些方向是由核心团队设定的，但核心团队的大部分或者全部成员都是谷歌的员工，所以在实际当中不可能分得很清楚。如果 Go 语言核心团队都离开了谷歌，并积极确立 Go 语言未来的发展方向，那我们或许可以说清楚 Go 语言到底属于谁。如果这件事情真的发生了的话，特别是大多数人不再为谷歌工作，那么 Go 语言就有可能属于这个团队。就像 Python 一样，不论 Guido van Rossum 为谁工作，Python 一直都是他的编程语言。
在实际当中，不能否认的是，谷歌为 Go 语言提供了大量的基础设施和资源，例如域名 golang.org 等，而且 Go 语言的商标同样也在谷歌的商标列表里面。
