Russ Cox (along with Rob Pike) is the tech lead for Google's Go team and its Go project. This week he responded on the Google group
golang-nuts to a blogger who'd argued that "
Go is Google's language, not ours."
First Cox points to a talk at Gophercon 2015 -- and
its accompanying blog post -- which argued that Go's open source status is critical to its long-term success. He noted this week that "good ideas come from outside Google as often as they come from inside Google.... But getting to yes on every suggested new
feature is not and never has been a goal."
No one can speak for the entire Go community: it is large, it contains multitudes. As best we can, we try to hear all the many different perspectives of the Go community. We encourage bug reports and experience reports, and we run the annual Go user survey, and we hang out here on golang-nuts and on gophers slack precisely because all those mechanisms help us hear you better. We try to listen not just to the feature requests but the underlying problems people are having, and we try, as I said in the Gophercon talk, to find the small number of changes that solve 90% of the problems instead of the much more complex solution that gets to 99%. We try to add as little as possible to solve as much as possible.
In short, we aim to listen to everyone's problems and address as many of them as possible, but at the same time we don't aim to accept everyone's offered solutions. Instead we aim to create space for thoughtful discussions about the offered solutions and revisions to them, and to work toward a consensus about how to move forward...
The "proposal review" group meets roughly weekly to review proposal issues and make sure the process is working. We handle trivial yes and trivial no answers, but our primary job is to shepherd suggested proposals, bring in the necessary voices, and make sure discussions are proceeding constructively. We have talked in the past about whether to explicitly look for people outside Google to sit in our weekly meeting, but if that's really important, then we are not doing our job right. Again, our primary job is to make sure the issues get appropriate discussion on the issue tracker, where everyone can participate, and to lead that discussion toward a solution with broad agreement and acceptance. If you skim through any of the accepted proposals you will see how we spend most of our meetings nudging conversations along and trying to make sure we hear from everyone who has a stake in a particular decision.
It remains an explicit goal to enable anyone with a good piece of code or a good idea to be able to contribute it to the project, and we've continued to revise both the code contribution and proposal contribution docs as we find gaps. But as I said in 2015, the most important thing we the original authors of Go can do is to provide consistency of vision, to keep Go feeling like a coherent system, to keep Go Go. People may disagree with individual decisions. We may get some flat wrong. But we hope that the overall result still works well for everyone, and the decision process we have seems far more likely to preserve a coherent, understandable system than a standards committee or other process.
His conclusion? The Go language belongs to the Go community -- and, because it's open source, "the freedom to fork hopefully keeps me and the other current Go leadership honest."
