I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?)
To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.
I think bdcravens means that to install Go from source on, say, a new Linux box, we will have to download a binary version of Go first, even though we probably already have gcc.
What happens if this catches on, and PyPy replaces CPython, and other languages do the same?
Hassles for those who prefer to install from source, and potentially a lot of duplication of effort writing compiler backends in every language.
I agree the installation issues are fairly trivial; they were just a response to the original comment.
But the duplication of effort (which won't end when the "GoGo" compiler is ready to replace cgo), and a potential freeze in Go while "GoGo" catches up, are more serious drawbacks.
Yes, that is a trade-off other compiler teams have made, and it may be the right choice for Go as well, but it should be (and no doubt has been) considered.
No, I was just pointing out a drawback. Of course there are advantages too.
In this particular case, though, I wonder why the Go team is planning to spend a lot of effort rewriting an already existing compiler. Rewriting a popular project from scratch can be a dangerous temptation.
Also, you don't have to download a binary of Go to compile the latest Go. You can download the Go source back when it was compiled by C, compile it, and then compile the later, Go-sourced versions, if for any reason you need to go that far.
To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.