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.

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.

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.

This claim is belied by the fact that half of the people who have committers in Go are non-Googlers, isn't it?

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...

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.

Open source =/= community driven.

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.

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.

Keeping as constant Go's opinionated (for better/worse) management philosophy, I don't think there's anything the Go team can say to put this criticism to bed. It's simple: Rails can be "omakase" because Basecamp is a tiny company, and Go can't be (without gripes) because Google is a big company. Hell, it wasn't even clear a few weeks ago whether Clojure was allowed to gripe-free "omakase" status, and hardly anyone on HN has even heard of Rich Hickey's company.

Since, short of drastically changing how the project is managed --- something I don't think many Go users have an appetite for --- there's nothing they can do rhetorically to shut the argument down, I think it's best ignored.

But I think the final paragraph of this post only serves to highlight an issue brought up in the original post by Mr. Siebenmann.

The rebuttal says:

"There are certainly senses in which Go is Google's language: it was created at Google, Google continues to fund most of the development, and a few people at Google are the final deciders about the language itself."

I understand that the language can be owned by Google and the community, but the original take was:

"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."

Seems like the rebuttal's concluding statement doesn't really address the biggest concerns.

The rebuttal continues to say that the development team tries to work with the community when possible. The original discussion here on HackerNews brought up examples where that is not always the case. I don't think a BDFL or a team acting as BDFL is a bad thing inherently, but I don't think this rebuttal really talks to the issues.

I once wanted to build a bunch of ML tools for Golang. Like coding up UMAP or other dimensionality reduction techniques, introducing some variational techniques, etc. But the package manager situation at the time (I thought of doing this 2 years ago) scared me off!

edit: I thought about this and did form a slight opinion on this article only. If we were to change the opening and concluding paragraph only (and retain the rest of the contents), it should have been titled "Go is Google's Language, and that is ok!" And then added a paragraph on how Google possibly abandoning the project wouldn't cripple it.

"..I've noticed that people often use the term “the Go community” without being particularly clear about what they mean. To me, the Go community is all Go users, which is at least a million people at this point. As such, it's at the very least imprecise to say things like “the Go community wants (or did) X.”

I think this is important because some outspoken members seems to have tendency to claim that they represent whole community and they must be heard and responded to even at the cost of quiet community members.

It seems like we will never hear the end of the apologias about how open Go is.

To me that betrays that it’s exactly the opposite.

I use Go, it’s useful, but i do so with a bad taste in my mouth: like someone’s stubborn opinions are being forced upon me.

It's this way with every Google OSS project I know of. Guava, Angular, AMP, Chrome, Android, Tensorflow, gRPC. Sometimes they even de-facto take over existing projects, like Square's Dagger DI.

Google has no open source governance model unlike Apache, the chaos that is Linux or rust, or even Java's JCP. Since a fork is so expensive to maintain over time, many of these projects are open source only in name. Google invests enough money to keep anyone from forking. Pennies for them compared to the huge marketshare they get for having massive "safe" OSS projects that companies won't worry about adopting.

I was hoping that this would address the package management fiasco, but it did not.