Given that you still need an external tool not provided by Go, I'm not sure it's "solved" until the community rallies around a single tool, like Ruby did with RubyGems and later Bundler.
Yes and no. This is about agreeing on a common file tree layout. It's not the end of the story: there is a separate effort (github.com/kardianos/vendor-spec) about agreeing on a common format for recording where code came from.
Once there is agreement on those, however, I am not sure how important it will be to agree on a single program, although there may end up being natural agreement anyway.
The Go community need not rally around a single text editor, because instead we agree on what Go source files are and that they are named *.go. It may be that something similar can happen here.
He's saying the community solved it, and the Go Team is using the best ideas from the community to start implementing a solution built into the Go tools.
This has been their policy from the start. The Go team knows that Google tends to handle dependency management differently from your standard project, so they left it to the community to help build and decide which tools and ideas work best for dependency management. Several have arisen, and the Go team has started implementing some of those ideas.
RubyGems was a separated project in the beginning. Ruby ships with RubyGems built-in only since version 1.9. And Bundler is still an independent project. Go is following the same way, letting the community experiment and gain experience, and then adopting what works well into the core project.
