Over on Twitter, I saw the following question (via):

There is lot of conversation around generics in #go, can't we have something like OpenGo, where community can implement generics , rather that waiting for official #go generics to happen ? Something like OpenJDK

There are many answers for why this won't happen, but one that does not usually get said out loud is that Go is Google's language, not the community's.

Yes, there's a community that contributes things to Go, some of them important and valued things; you only have to look at the diversity of people in CONTRIBUTORS or see the variety of people appearing in the commits. But Google is the gatekeeper for these community contributions; it alone decides what is and isn't accepted into Go. To the extent that there even is a community process for deciding what is accepted, there is an 800-pound gorilla in the room. Nothing is going to go into Go that Google objects to, and if Google decides that something needs to be in Go, it will happen.

(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)

Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.

(As a corollary, sinking a lot of time and effort into a community effort that doesn't have enthusiastic buy-in from the Go core team is probably a waste of time; at the most, your work might help the Go core team understand the issues better. Again, see Go modules for this in action.)

In general, it's extremely clear that the community's voice doesn't matter very much for Go's development, and those of us working with Go outside Google's walls just have to live with that. If we're very lucky, our priorities match up with Google's; if we're reasonably lucky, the Go core team and Google will decide that they care enough about our priorities to work on them. The good news is that Google and the Go core team do care (so far) about Go being a success in the outside world, not just inside Google, so they're willing to work on pain points.

(On the good and bad scale, there is a common feeling that Go has done well by having a small core team with good taste and a consistent vision for the language, a team that is not swayed by outside voices and is slow moving and biased to not making changes.)

PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.

(And claims by the Go team that they really care about the community and want them to be involved now sound laughable. I'm sure they care, but only up to a certain point. I think that the Go core team should be bluntly honest about the situation, rather than pretend and implicitly lead people on.)

Sidebar: Google and the Go core team

You could ask if Go is Google's language or the Go core team's language, since Go's direction is set and controlled by that small core team. However, at the moment I believe that most or all of the active Go core team is employed by Google, making the distinction impossibly to determine in practice (at least from outside Google). In practice we'll only get a chance to find out who Go really belongs to if Go core team members start leaving Google and try to remain active in determining Go's direction. If that works, especially if the majority of them no longer work for Google, then Go probably is their language, not Google's, in the same way that Python has always been Guido van Rossum's language regardless of who he worked for at the time.

On a practical level, it's undeniable that at the moment Google provides much of the infrastructure and resources to support Go, such as golang.org, and as a result owns the domain names and so on. Google also holds the trademarks on 'Go' as a programming language, per their trademarks list.