Sure, but it's also a common solution outside of Go. I write iPhone apps and we have all of our major dependencies forked, because at some point you're going to butt up against the limits of what your lib does. Even just redirecting a git submodule at a later point is a minor brainfuck - so nowadays we just instinctively fork as soon as we decide to pull it in as a dependency.
What I really want to know is why they chose Go in the first place. Go isn't a game development language and it has little to no support, documentation, or just plain old previous community experience in the gaming context. This feels like the classic software development of putting the technology ahead of the product - using a tool because it's cool, rather than using it because it's the best thing for the job.
It's all about shipping, people. Use whatever you need to you can ship what you want, when you want to, at the quality and reliability you desire.
Back when I worked on a large commercial Python project, we did the same thing. All dependencies where on our server and that's the only place we grabbed them from when building a new release.
I think the main problem is that we got used to these dependency tools, and many developers coming to Go don't have experience how development was done before they came into existence.
Or the fact that many developers look at the previous methods and quite rightly say "That is a hideous method, we have moved on (and IMHO improved) from that, why the hell has a new language reverted to old and busted methods"
As I said in another comment regarding Go. If any company has the ability to create a stable, maintained CPAN / rubygems equivalent for the Go language, it would be Google.
Which just makes the lack of it more jarring (although I see the arguments that Go is designed for Google and may not fit other's ideas of what important features are)
