9 ms·

Not sure what to make of this. All of the points the author makes are obvious; of course a project originated at Google would have a majority-Google membership.

Not sure what to make of this. All of the points the author makes are obvious; of course a project originated at Google would have a majority-Google membership. Of course anyone is free to fork Go. Of course the code can be considered FOSS. Of course execs at Google couldn't care less about spec details. None of those things disprove the point that Go is not a community-driven project. I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply. The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone. The difference between an OpenJDK and an OpenGo project, in practice, would be that the two would be completely unrelated. Go core would go on ignoring community progress and, at best, Google would sue for the project to change the name and force a hard fork.

DannyBee 7y ago
"I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution:" Can you explain why it makes sense to generalize a company of 50k developers, which has released 4000+ open source projects, on the basis of precisely 1 of them? Why doesn't it make sense that it will end up with a variety of projects with a variety of models? Especially given that is true of the world writ large? I simply do not understand this fixation with trying to rigidly pigeonhole Google on open source.
- fellellor 7y ago
  The idea is to embarrass Google as an organization into changing their culture or at least the optics surrounding that culture.
- onion2k 7y ago
  I think the point rmrfrmrf is making is that Guava is a typical example of Google's attitudes towards the two-way relationship of open source. Google developers (and many other big software companies) are more than happy to open their code and promote it as something that the community should adopt, but seem rigidly dismissive of any code contributions to the project from outside. That may not be the case for every Google project but it does feel like it's a common one to me. What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?
  - Kamshak 7y ago
    Angular for example. They even hire non Google contributors to work more closely with them and have contributors programs to include the community
  - dodobirdlord 7y ago
    Kubernetes, probably. https://github.com/kubernetes/community/tree/master/contributors/guide https://github.com/kubernetes/community/tree/master/contribu...
    - solidasparagus 7y ago
      Kubernetes is a CNCF project. That's different than a project that Google runs.
    - hrktb 7y ago
      Kubernetes is a reaction to that state of closeness, and was explicitely designed to bring Google’s philosophy (Borg) to the world. Its strong focus on getting outside people involved is the core reason of its existence, so it’s a bit of a special case IMO.
  - hyperpallium 7y ago
    An issue is copyright ownership. Even if a contributor assigns copyright, it is ineffective if they didn't hold copyright. This opens the project to legal peril.
    - onion2k 7y ago
      That sounds reasonable except Google could write some boilerplate for maintainers to include in a project's README.md, contributing.md or license file that explicitly states they won't accept community contributions because copyright would be an issue, and they don't appear to have done anything like that.
      - hyperpallium 7y ago
asdfasgasdgasdg 7y ago
> I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply. This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?
- mbreese 7y ago
  It's probably less than half due to people using person email addresses instead of @google.com. The author didn't verify that people who had non-google addresses didn't actually work for Google. One thing I'd be curious to know is how many of the committers didn't ever work for Google. I suspect some of the non-Googlers on the committer list maybe former Googlers...
  - chocolatebunny 7y ago
    In the context of this discussions why would it matter if someone never worked at Google vs someone who used to work at Google. They're not acting on behalf of Google when they make the contribution.
    - mbreese 7y ago
      I don’t think it would necessarily matter. But it might be an indication of how “open” Google is to complete outsiders as opposed to people who were insiders but now just happen to not work for Google. Whether or not that matters is another question entirely. But like I said, I don’t think it matters in the context of how much control Google has over the language. Many successful languages are either driven by an individual benevolent dictator or a company. As far as I can tell, languages controlled by community/committees tend to evolve more slowly. That’s okay at some point in a project. But there is something to be said for a person/company having the ability to rapidly push through changes.
  - Carpetsmoker 7y ago
    You need to sign a CLA to work on Go, like most Google projects. You can't accidentally use your personal email address, and setting up the CLA signing stuff is somewhat involved.
ummonk 7y ago
Right. For better or for worse, Go is not a community-driven project. It is a project driven by a (largely independent) team within Google. Open source =/= community driven.
stcredzero 7y ago
The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone. NIH syndrome was widely cited as one of the major flaws of the Smalltalk community back in the day. In any human endeavor, one has to fight the tendency of a group turning something which isn't a club, into a club. That said, golang isn't a field. It isn't a genre. It's a computer language, a collection of libraries, and a number of online communities. In large part, it's a collection of tools with support around it, people interested in using it, and a company behind it. There are lots of things like this. Leica cameras. Rigol oscilloscopes. Chevy LS3 crate engines. Harley Davidson Motorcycles. These things live and die by continuing to garner the goodwill of the market and staying honest with themselves. On the flip side, many of those things also live or die through good design, and good design also needs gatekeepers and visionaries. It's a balancing act. Golang in particular needs to watch its step. Since it has a syntax on the minimalist side with few surprises and easy access to its AST, it's going to be one of the easier languages to port off of.
liveoneggs 7y ago
indeed but there are so many more clear examples :) rsc@'s clear disdain that anyone outside of google would run go is crystal clear in many of his various writings on issues like clock skew, packaging, etc It's lucky bradfitz is, apparently, able to remember that a world outside of google exists.
- dullgiulio 7y ago
  Quick reminder that leap seconds smear is also required for Java 8+.
oconnor663 7y ago
> the tedium of dealing with the unwashed masses -- typical NIH syndrome If you've managed a large OSS project with a wide userbase before, you know how annoying it can be to deal with large numbers of repetitive requests from folks who don't have the full context of what's going on in the project. It's time consuming at best, and at worse some small minority of those folks take up a toxic attitude that sucks the happiness out of your work. There's no need to accuse maintainers of arrogance or NIH syndrome. This stuff is hard, and we all try to do the best we can.
- 0815test 7y ago
  > ...repetitive requests from folks who don't have the full context of what's going on in the project Write some FAQ's, so that people are made aware of that context. An openly-developed project can actually be very successful at dealing with this, because pointing folks to the centralized discussion in which the pros and cons of commonly-requested feature X are dealt with becomes second nature after a while. We saw an example of this very recently with the surprisingly-mild brouhaha about Rust's choice of a postfix .await syntax.
  - Carpetsmoker 7y ago
    There's an FAQ: https://golang.org/doc/faq https://golang.org/doc/faq For generics specifically, there's a "Summary of Go Generics Discussions", which is quite comprehensive: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
  - unionpivo 7y ago
    From my experience as oss developer on several different projects (small to medium ones),a lot of people don't bother to read FAQ's. There are some people that hit the problem, start googling, and trying to find information, and some that just fire off email or stack overflow question (often so badly, you need several back and forth)
why-el 7y ago
> Go core would go on ignoring community progress Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less. I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.
- pjmlp 7y ago
  Yet other language communities managed to do it since the mid-70's.
  - chewxy 7y ago
    I put it to you that most other language communities do not deliberate as much on generics. Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md https://github.com/golang/proposal/blob/master/design/15292/... More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-thoughts-on-generics-in-go https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho... The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
    - coldtea 7y ago
      There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour". Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor". That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
mda 7y ago
Can you point us where Guava library team made such claims?
- NovaX 7y ago
  I believe the author is referring to this post, https://web.archive.org/web/20181209143223/https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM https://web.archive.org/web/20181209143223/https://plus.goog... Guava was always made available as Google's Java core utilities. I think it was always a misunderstanding to expect external contributions, like Apache Commons, as that was not its original intent. Rather it was to reduce internal duplication and ad hoc code with a shared standard. It then became useful for open-sourced Google projects (like API clients) and recruiting (new hires would be familiar with Google's libraries). Many suggestions are best spun off into new libraries, rather than donated to Google to maintain. Java's many flaws have been papered over by a large ecosystem of libraries. As a non-gopher, I'm not sure if that same spirit exists. Perhaps that is due to the dependency debates, whereas Maven Central was quickly adopted when managing jars (via Ant) became too burdensome. Perhaps modules will help, as the language doesn't have to be batteries included.
cromwellian 7y ago
Any OSS project can be relatively closed to outside contributors based on how opinionated the core owners of the repo are, it isn't just corporate open source. You think the Guava team has a low opinion of patches? Does that mean Linux isn't a community project because Linus wields an iron fist when it comes to accepting patches?
- pas 7y ago
  Yet Linux is full if half-assed undocumented cruft despite Linus' vigilance. It's just gigantic. He doesn't care much about how great your new LSM, IO scheduler, FS is, if it's relatively sane, and you don't do crazy things elsewhere in the code, he'll pull it. (Nowadays it's not directly him.)
  - rswail 7y ago
    How much of it is device drivers for arcane devices though?
KerrickStaley 7y ago
A counter-example I've seen is Bazel; the Bazel core team seems very receptive to outside contributions and feedback from my experience (I've contributed PRs to Bazel). (I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).
joatmon-snoo 7y ago
The set of people that make decisions about Guava is mutually exclusive from the set of people that make decisions about Go, and the two projects have markedly different goals. It's also worth noting that Guava lives in a very different world from Go - the way we distribute Guava is (unfortunately) not designed for non-Google contributors and Guava needs to support multiple Java ecosystems/platforms (Android and servers, at least). (Googler that works on neither Guava nor Golang.)

DannyBee 7y ago

"I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution:" Can you explain why it makes sense to generalize a company of 50k developers, which has released 4000+ open source projects, on the basis of precisely 1 of them? Why doesn't it make sense that it will end up with a variety of projects with a variety of models? Especially given that is true of the world writ large? I simply do not understand this fixation with trying to rigidly pigeonhole Google on open source.

fellellor 7y ago
The idea is to embarrass Google as an organization into changing their culture or at least the optics surrounding that culture.
onion2k 7y ago
I think the point rmrfrmrf is making is that Guava is a typical example of Google's attitudes towards the two-way relationship of open source. Google developers (and many other big software companies) are more than happy to open their code and promote it as something that the community should adopt, but seem rigidly dismissive of any code contributions to the project from outside. That may not be the case for every Google project but it does feel like it's a common one to me. What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?
- Kamshak 7y ago
  Angular for example. They even hire non Google contributors to work more closely with them and have contributors programs to include the community
- dodobirdlord 7y ago
  Kubernetes, probably. https://github.com/kubernetes/community/tree/master/contributors/guide https://github.com/kubernetes/community/tree/master/contribu...
  - solidasparagus 7y ago
    Kubernetes is a CNCF project. That's different than a project that Google runs.
  - hrktb 7y ago
    Kubernetes is a reaction to that state of closeness, and was explicitely designed to bring Google’s philosophy (Borg) to the world. Its strong focus on getting outside people involved is the core reason of its existence, so it’s a bit of a special case IMO.
- hyperpallium 7y ago
  An issue is copyright ownership. Even if a contributor assigns copyright, it is ineffective if they didn't hold copyright. This opens the project to legal peril.
  - onion2k 7y ago
    That sounds reasonable except Google could write some boilerplate for maintainers to include in a project's README.md, contributing.md or license file that explicitly states they won't accept community contributions because copyright would be an issue, and they don't appear to have done anything like that.
    - hyperpallium 7y ago

asdfasgasdgasdg 7y ago

> I think I've mentioned this a while back, but one only needs to look to the Guava library team to see what Google's general position is on community contribution: contributors need not apply. This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?

mbreese 7y ago
It's probably less than half due to people using person email addresses instead of @google.com. The author didn't verify that people who had non-google addresses didn't actually work for Google. One thing I'd be curious to know is how many of the committers didn't ever work for Google. I suspect some of the non-Googlers on the committer list maybe former Googlers...
- chocolatebunny 7y ago
  In the context of this discussions why would it matter if someone never worked at Google vs someone who used to work at Google. They're not acting on behalf of Google when they make the contribution.
  - mbreese 7y ago
    I don’t think it would necessarily matter. But it might be an indication of how “open” Google is to complete outsiders as opposed to people who were insiders but now just happen to not work for Google. Whether or not that matters is another question entirely. But like I said, I don’t think it matters in the context of how much control Google has over the language. Many successful languages are either driven by an individual benevolent dictator or a company. As far as I can tell, languages controlled by community/committees tend to evolve more slowly. That’s okay at some point in a project. But there is something to be said for a person/company having the ability to rapidly push through changes.
- Carpetsmoker 7y ago
  You need to sign a CLA to work on Go, like most Google projects. You can't accidentally use your personal email address, and setting up the CLA signing stuff is somewhat involved.

ummonk 7y ago

Right. For better or for worse, Go is not a community-driven project. It is a project driven by a (largely independent) team within Google. Open source =/= community driven.

stcredzero 7y ago

The maintainers there blogged at-length about the inferiority of non-Googlers and the tedium of dealing with the unwashed masses -- typical NIH syndrome -- this is the same philosophy that the Go team is influenced by, perhaps with only a less hostile tone. NIH syndrome was widely cited as one of the major flaws of the Smalltalk community back in the day. In any human endeavor, one has to fight the tendency of a group turning something which isn't a club, into a club. That said, golang isn't a field. It isn't a genre. It's a computer language, a collection of libraries, and a number of online communities. In large part, it's a collection of tools with support around it, people interested in using it, and a company behind it. There are lots of things like this. Leica cameras. Rigol oscilloscopes. Chevy LS3 crate engines. Harley Davidson Motorcycles. These things live and die by continuing to garner the goodwill of the market and staying honest with themselves. On the flip side, many of those things also live or die through good design, and good design also needs gatekeepers and visionaries. It's a balancing act. Golang in particular needs to watch its step. Since it has a syntax on the minimalist side with few surprises and easy access to its AST, it's going to be one of the easier languages to port off of.

liveoneggs 7y ago

indeed but there are so many more clear examples :) rsc@'s clear disdain that anyone outside of google would run go is crystal clear in many of his various writings on issues like clock skew, packaging, etc It's lucky bradfitz is, apparently, able to remember that a world outside of google exists.

dullgiulio 7y ago
Quick reminder that leap seconds smear is also required for Java 8+.

oconnor663 7y ago

> the tedium of dealing with the unwashed masses -- typical NIH syndrome If you've managed a large OSS project with a wide userbase before, you know how annoying it can be to deal with large numbers of repetitive requests from folks who don't have the full context of what's going on in the project. It's time consuming at best, and at worse some small minority of those folks take up a toxic attitude that sucks the happiness out of your work. There's no need to accuse maintainers of arrogance or NIH syndrome. This stuff is hard, and we all try to do the best we can.

0815test 7y ago
> ...repetitive requests from folks who don't have the full context of what's going on in the project Write some FAQ's, so that people are made aware of that context. An openly-developed project can actually be very successful at dealing with this, because pointing folks to the centralized discussion in which the pros and cons of commonly-requested feature X are dealt with becomes second nature after a while. We saw an example of this very recently with the surprisingly-mild brouhaha about Rust's choice of a postfix .await syntax.
- Carpetsmoker 7y ago
  There's an FAQ: https://golang.org/doc/faq https://golang.org/doc/faq For generics specifically, there's a "Summary of Go Generics Discussions", which is quite comprehensive: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
- unionpivo 7y ago
  From my experience as oss developer on several different projects (small to medium ones),a lot of people don't bother to read FAQ's. There are some people that hit the problem, start googling, and trying to find information, and some that just fire off email or stack overflow question (often so badly, you need several back and forth)

why-el 7y ago

> Go core would go on ignoring community progress Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less. I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.

pjmlp 7y ago
Yet other language communities managed to do it since the mid-70's.
- chewxy 7y ago
  I put it to you that most other language communities do not deliberate as much on generics. Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md https://github.com/golang/proposal/blob/master/design/15292/... More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-thoughts-on-generics-in-go https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho... The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
  - coldtea 7y ago
    There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour". Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor". That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...

mda 7y ago

Can you point us where Guava library team made such claims?

NovaX 7y ago
I believe the author is referring to this post, https://web.archive.org/web/20181209143223/https://plus.google.com/113026104107031516488/posts/ZRdtjTL1MpM https://web.archive.org/web/20181209143223/https://plus.goog... Guava was always made available as Google's Java core utilities. I think it was always a misunderstanding to expect external contributions, like Apache Commons, as that was not its original intent. Rather it was to reduce internal duplication and ad hoc code with a shared standard. It then became useful for open-sourced Google projects (like API clients) and recruiting (new hires would be familiar with Google's libraries). Many suggestions are best spun off into new libraries, rather than donated to Google to maintain. Java's many flaws have been papered over by a large ecosystem of libraries. As a non-gopher, I'm not sure if that same spirit exists. Perhaps that is due to the dependency debates, whereas Maven Central was quickly adopted when managing jars (via Ant) became too burdensome. Perhaps modules will help, as the language doesn't have to be batteries included.

cromwellian 7y ago

Any OSS project can be relatively closed to outside contributors based on how opinionated the core owners of the repo are, it isn't just corporate open source. You think the Guava team has a low opinion of patches? Does that mean Linux isn't a community project because Linus wields an iron fist when it comes to accepting patches?

pas 7y ago
Yet Linux is full if half-assed undocumented cruft despite Linus' vigilance. It's just gigantic. He doesn't care much about how great your new LSM, IO scheduler, FS is, if it's relatively sane, and you don't do crazy things elsewhere in the code, he'll pull it. (Nowadays it's not directly him.)
- rswail 7y ago
  How much of it is device drivers for arcane devices though?

KerrickStaley 7y ago

A counter-example I've seen is Bazel; the Bazel core team seems very receptive to outside contributions and feedback from my experience (I've contributed PRs to Bazel). (I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).

joatmon-snoo 7y ago

The set of people that make decisions about Guava is mutually exclusive from the set of people that make decisions about Go, and the two projects have markedly different goals. It's also worth noting that Guava lives in a very different world from Go - the way we distribute Guava is (unfortunately) not designed for non-Google contributors and Guava needs to support multiple Java ecosystems/platforms (Android and servers, at least). (Googler that works on neither Guava nor Golang.)