@rrfeng #31

简单的总结一下

Russ：我有管理责任，我道歉。dep 一开始就不是作为官方实现，是个实验，你们想多了。我想要 sementic import versioning，dep 不支持，所以没法把 dep 集成到 go 中。现在我搞了 go module Proposal 和原型实现(vgo)，大家都说好。

dep 的开发者：

当 dep 委员会成立的时候，我竭尽所能的，让它以及它推进的工作，尽可能的可靠和无懈可击，以保护工作组的信用，工作组成员的声誉，以及产出的产品的有效性。为了代替自核心团队的指导，甚至基本的交流，我们决定：
- 从社区的领袖和专家中征集成员
- 成立一个次级的顾问组支持所有相关的项目
- 花费了半年时间收集用户反馈和进行领域内的研究
- 详细 Review 了所有其他有意义的包管理工具
- 步调一致的进行设计，目标在所有的主要决策上达成一致
- 所有的一切，都煞费苦心的，公开的记录文档

我们做了所有的这一切，因为我们想要成为社区能够更近一步，解决一直被核心团队忽视的问题的典范。我无法找到比我们比我们所做过的事情更好的事情了。但是结果，这些努力就像我们从来没有做过任何事一样：核心团队最终不参与进我们所贡献的成果上面，而是坚持自己完成，本质上一个全新的重头开始的项目。

我想 dep/vgo 的结局很好的说明了，虽然 Go 领导层很乐意接受对 issue 和无争议的 Proposal 这样的贡献，但仍然在与大规模的自主自治的贡献者斗争。权利掌握在 Google 的核心开发团队里。

如果有一天我做关于这个最终失败的项目的演讲，我要在最后放一页幻灯片，上面有一个图，一艘船在岛上失事了，船长说: "你生命的意义就在于警告其他人"。我希望这个故事给别人一个警告："如果你有兴趣对 Go 做出大的实质性的贡献，独立的勤奋工作不能补偿你那不是来自核心团队的设计"。


----
Addendum(作者看完在 Reddit 上的讨论添加的)：
这次引发的讨论启发了我。我想我对于发生的事情，有了更好的全景的视角。我认为 dep 团队和核心团队各自有完全不同的对对话的理解，直到 vgo 文章的出现让量子态塌缩了。

Dep 团队相信 dep 和之前出现的工具是不一样的，是一个经过研究和详细考虑，社区驱动的最终 go 依赖管理解决方案。核心团队认为 dep 和之前的工具本质上是同一类，是他们设计的最终的方案的前奏的一部分。

我相信 dep 团队很清楚他们的地位，能够从核心团队的表述中能够看出来是处于什么样的地位的。但是明显(dep 团队成员)没有能够普遍的理解这个地位，直到为时已晚，直到已经太晚。唉，事后来看是很显然的事情，但是当时谁又能够看得透呢?