Earlier this month, the Hacker News community got into a heated debate on whether “Go is Google’s language, and not the community’s”. The thread was first started by Chris Siebenmann who works at the Department of Computer Science, University of Toronto. His blog post reads, “Go has community contributions but it is not a community project. It is Google’s project.” In response to his statements, last Thursday, Ian Lance Taylor, a googler and member of the Golang team added his own views on a Google group mailing list, that don’t necessarily contradict Chris’s blog post but add some nuance.
Ian begins with a disclaimer: “I’m speaking exclusively for myself here, not for Google nor for the Go team.” He then reminds us that Go is an open source language considering all the source code, including for all the infrastructure support, is freely available and may be reused and changed by anyone. Go provides all developers the freedom to fork and take an existing project in a new direction. He further explains how there are 59 Googlers and 51 non-Googlers on the committers list which includes the set of people who can commit changes to the project. He says, “so while Google is the majority, it’s not an overwhelming one.”
Golang has a small core committee which makes decisions
Contradicting Chris’s opinion of how Golang is only run by a small set of people which prevents it from becoming the community’s language, he says, “All successful languages have a small set of people who make the final decisions. Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence. I believe that every successful language must have a coherent vision that is shared by a relatively small group of people.” He then adds, “Since Go is a successful language, and hopes to remain successful, it too must be open to community input but must have a small number of people who make final decisions about how the language will change over time.”
This makes sense. The core team’s full-time job is to take care of the language instead of taking errant decisions based on community backlash. Google will not make or block a change in a way that kills an entire project. But this does not mean they should sit idly, ignoring the community response. Ideally, the more than a project genuinely belongs to its community, the more it will reflect what the community wants and needs.
Ian defends Google as a company being a member of the Golang team, saying they are doing more work with Go at a higher level, supporting efforts like the Go Cloud Development Kit and support for Go in Google Cloud projects like Kubernetes. He also assures that executives, and upper management in general, have never made any attempt to affect how the Go language and tools and standard library are developed. “Google, apart from the core Go team, does not make decisions about the language.”
What if Golang is killed?
He is unsure of what will happen if someone on the core Go team decides to leave Google but wants to continue working on Go. He says, “many people who want to work on Go full time wind up being hired by Google, so it would not be particularly surprising if the core Go team continues to be primarily or exclusively Google employees.” This reaffirms our original argument of Google having a propensity to kill its own products. While Google’s history shows that many of their dead products are actually an important step towards something better and more successful, why and how much of that logic would be directly relevant to an open source project is something worth thinking about.
He further adds, “ It’s also possible that someday it will become appropriate to create some sort of separate Go Foundation to manage the language.” But did not specify what such a foundation would look like, who its members will be, and how the governance model will be like. Will Google leave it to the community to figure out the governance model suddenly by pulling off the original authors into some other exciting new project? Or would they let the authors only work on Golang in their spare time at home or at the weekends?
Another common argument is on what Google has invested to keep Go thriving and if, the so-called Go foundation will be able to sustain a healthy development cycle with low monetary investments (although GitHub sponsors can, maybe, change that). A comment on Hacker News reads, “ Like it or not, Google is probably paying around $10 million a year to keep senior full-time developers around that want to work on the language. That could be used as a benchmark to calculate how much of an investment is required to have a healthy development cycle.
If a community-maintained fork is created, it would need time and monetary investment similar to what Google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?”
In general, though, most people/developers agreed with Ian. Here are a few responses from the same mailing list:
“I just want to thank Ian for taking the time to write this. I’ve already got the idea that it worked that way, but my own deduction process, but it’s good to have a confirmation from inside.”
“Thank you for writing your reply Ian. Since it’s a rather long post I don’t want to go through it point by point, but suffice it to say that I agree with most of what you’ve written.”
Read Ian’s post on Google Forums.
Read Next
Is Golang truly community driven and does it really matter?
GitHub releases Vulcanizer, a new Golang Library for operating Elasticsearch
