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.
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.
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.
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.
What Google projects would make good counterpoints by demonstrate a welcoming attitude to external contributions?
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.
Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.
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...
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.
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?
Open source =/= community driven.
(I don't use Go, so I don't have much insight into the overarching discussion. Just wanted to add my 2c).
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.)
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.
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.
If you don't want to use a project affiliated with Google, don't code in Go. Similarly, if you want to have large solo impact on core features of a language platform, like package management, set your sites somewhere other than Go, where fairly intensive gatekeeping to that kind of stuff is widely considered a feature, not a bug.
While Google is certainly a big bish in that pond, there are plenty of other big fish to balance them out, including Cisco, Red Hat/CoreOS, Github, IBM, Intel and Docker.
Or invent a new organization. Call it "the Go Foundation". Make sure it's independent and has the bylaws and administrative structure to prove it. It's worked out pretty well for Python [2].
Example: I don't like all the things gofmt does, but if I accept what gofmt gives me, I can learn to live with it, and eventually be super happy :)
If go isn't opinionated, then what's the point? Whether owned by Google or a foundation, if the core team isn't small and opiniated, then aren't we just reinventing C++, hehe :)
Disclaimer: I work for Google, this is my personal opinion. (I actually haven't used golang since joining Google, but that's a different story)
We see something similar in the Java world. Even though the Java stewards are mostly Oracle employees, Oracle does not exert direct control over stewardship; the OpenJDK lead is elected by the OpenJDK board (whose chairmanship is reserved for Oracle, but has non-Oracle members). However, Oracle also funds 90% of the OpenJDK contributors, and the company can decide they want to fund work in certain areas but not in others. E.g. Oracle has reduced investment on client-side Java; some of that work is now contributed by another corporation (Gluon), but the total resources for client work are still reduced.
Because Google has many people working on OpenJDK (I think about the same number as those working on Go), it also has a lot of influence, as it can contribute large features (like the thread sanitizer they're now contributing).
Here is an explanation of Java's governance by Mark Reinhold, who is the OpenJDK lead and also Chief Architect of the Java Platform Group at Oracle: https://youtu.be/HpbchS5kmio
Who will run it? Activists ? You want the top talent working in/on go to be the people that run it. Now if GvR (python) or equivalent was contributing to go and he is hey I’m an awesome developer and an awesome language designer what gives with side lining me.
That would be a point. But now most top go talent that are working on the language are at google
Just like with k8s google may create a foundation for it or donate to one of the existing one when there is diversity in top contributors. I assume hope. Perhaps this activism is early
In this specific case (which is important to the discussion) there effectively was nothing you could call "management" in what the core tooling provided for resolving and fetching dependencies. I think the reason it wasn't there, was because that wasn't very important to Google which famously operates a company-wide mono repo. Dependency management wasn't a problem Google had, so an official solution was a very long time coming, and left the interim solution providers feeling quite raw.
For what it's worth (and I say this is an outside observer who's never written any Go, so, grain of salt, etc.), I don't think the original post this responds to disagrees with your point. To wit, from that post:
> 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.
and
> 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 don't think he's saying "Go is bad" or even "the management of Go is bad," but rather something more like "people should be honest about the nature of the management of Go, and choose how to engage with the community and the process accordingly."
Go _is_ Google's project. They may let other people contribute but if Google's interests are not maintained, and further if the small core group who run it inside of Google disagree, you should not assume there is any way to override that. That's literally the point of what the original document was saying.
Lots and lots of us can live with that, but it would be much better if the golang contribution process was more explicit about that.
And with that lack of difference in mind: when the Go team says "Google's interests have little to do with how we're running Go", I'm strongly inclined to believe them, because what difference does it make? Why would they just make it up?
But really my point here is just: there's no point in the Go team engaging on this, because I literally can't think of a single thing Russ Cox could say to defuse this drama.
Quite a few of the core Go devs aren't hired by Google out of the general programming pool, they were already contributing to Go and then Google asked "hey, cool stuff; why not come work on Go for us?" Again, this is pretty much how you join any core group of developers: make good contributions, get asked. Except here you actually get paid.
Responding with, in essence, "but we love the community!" is great, and probably true, but...unless it's followed up by "...and that's why we feel so badly about the previous events, and have made these specific changes" (or at the minimum a rebuttal of the specific criticisms), it doesn't really....mean anything?
Keep in mind, the closest we've got to introspection from Cox about the modules issue was a "I'm sorry everyone else is upset, I must have not explained things well enough" non-apology. Which is fine! The Go team doesn't need to apologise for running their language development process however they see fit...but it does underscore the issue.
Fundamentally, a decent chunk of the Go community thinks that the modules process was fundamentally broken, and the Go team thinks the modules process was fundamentally fine. I would interpret the subtext of Cox's post as "we really wish the community would be fine with the process". No doubt.
Finally, there's something a bit patronising about this:
> I spent a while trying to work out what I want to say about the general theme of Go and open source, but in the end I realized that my talk at Gophercon 2015 is a better articulation of what open source means for Go, and what Google's role is, than any email I can write in a few hours today. You can read the blog post version, “Go, Open Source, Community,” at https://blog.golang.org/open-source, and I am including a copy below. I reread it this morning, and I still believe everything I said then.
The current discussion is about events after 2015, by people who are well aware of that talk. If people are questioning how the Go team is interacting with the community even after that talk, then maybe it isn't sufficient, and you need to do more than just tell everyone to read it again?
Again, outside observer as a non golang user, but this is my impression. Any non-Google's contributing care to share experiences.
This perceived (on my part) hostility to the non Google user community definitely keeps me from even taking a look at it. I use C++, C# and Python professionally. I'd potentially give Rust a go if I had time to learn it (my job currently wouldn't allow it, as we're mainly a C# shop, only now branching into Python - few of the main reasons I was hired was business domain knowledge and +15 years experience in both C# and Python).
My 3 main languages all have active engagement with their user community and 2 of the 3 aren't controlled by a single corporation. C# is definitely driven by MS, bit they are actively engaged with their development community and listen to feedback and accept PRs for .Net Core.
That seems fair, yes. Although while some people are unhappy because they're just not fans of that model, I think more of the unrest is because the Go team keeps saying they want it to be more community driven, and then there being a (perceived) disconnect between intentions and reality.
If your language has a BDFL, and they make arbitrary decisions, well, what did you expect? And lots of people are fine with that, and if you're lucky then, like Python, you can eventually transition to a more community driven model.
Sometimes it seems to me that the only people who think Go isn't being run exclusively by the Go team are the Go team themselves. :)
Admittedly, not all MS OSS projects are equal, there are a number of "here's the code", but it's going to be driven internally, versus a more traditionally driven mix of a primary corporate driver and OSS community contributions.
One of the things I'd love to see is a bespoke cross platform DB API. I'm currently using zillow's cTDS lib, which has been great, except it can't support table valued parameters, because FreeTDS doesn't. Yet pytds supports SVTPs, but seems to only support bulk copy via a file.
I wish that MS would provide a bespoke lib that provided all of this functionality (TVPs and BCP without an intermediate file).
I posted my perception as a nonuser, non member of the golang community, but with my perception of my perceived hostility against non googler memebers of the community...and I get met with no comments and downvotes, which reinforces my perception (deservedly or not) of hostility towards non-googler involvement in golang development. So, yeah, thanks. Golang is something I will now not likely something I will ever pursue.
Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.
There are many who would dispute your assertion very vigorously. I mean...the core issue was being able to have semantic import versioning, which is a feature most languages used in very large projects do not have. (And the most widely used language to try and solve the underlying issue is node, which is not well known for its suitability for large, complex projects, so...) And Cox tried and failed to explain why he thought semantic import versioning was important to a committee that included many people who had worked on large projects written in Go and other languages, so...must be a bit of a subtle issue. :)
But sure. Fine. Let's just accept your entire claim as fact for the sake of argument, because even so, the real concerns here have nothing do with whether or not dep was fit for purpose, it has to do with the Go team's unwillingness to work with the community over what it would mean for a modules tool to be fit for purpose.
If you piece together the different accounts, we can say with some confidence what happened, and it's pretty clear that the core issue is the dep team wanted to work with the Go team on a solution that met the needs of everyone, and the Go team did not, so they didn't.
Which is fine, of course. Cox had every right to refuse to talk to the dep team, throw their work away, and re-implement it from scratch. I'm sure he enjoyed developing vgo, and perhaps it even saved him time compared to having to explain his ideas to the plebians on the dep committee...but even if so, that's not how you have a successful community driven project.
> Rust does the right thing there, this is a fact.
Ironic then, that dep was a straight up effort to copy Cargo, and most critic's of the Go teams management of the language have looked to Rust as an inspiration.
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.
Then why use it? Is there really nothing better?
For me it's good enough for some small tasks. I could find something better, but it's not worth it in some cases.
"..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.
This seems a little implausible to me, can this really be the case?
Edit: Oh, I see the reference in the post https://research.swtch.com/gophercount (I'm still skeptical!)
The minor issue is the quantifying of developers. The methodology for the 15-20 million figure isn’t clear, but it at least passes some basic sniff test.
What’s completely bullshit is using stackoverflow surveys. There is no reason to believe the respondents of that survey are an unbiased cross section of the 20 million and many reasons to believe they aren’t.
I would totally expect the stackoverflow social 2.0 tech hipster webshit crowd that would fill out that dumb survey to be more likely to use Go. The same with oreilly surveys. Old grizzled grey beards aren’t as likely to fill out publisher surveys on old stable tech.
Also, answering that you have “used” go is not the same as being a regular developer (as noted by one of the commenters there... assembly is more “popular” than Go).
Activist: "Over two million Americans signed our petition. You must do something!"
Politician: "So that means over 320 million didn't sign it. The majority clearly likes how things are!"
> You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
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 personally like to have strong leadership behind such fundamental things as languages. I may not agree with all of their decisions, but at least I can count on the stability, which we all need in order to collaborate successfully. With strong leadership, I know I we won't have another Python2 vs Python3 mess.
And the ability to fork is very handy. I've forked my own golang compiler to allow warnings for unused imports, variables, etc [1] because I don't like fighting the compiler during debug or exploratory coding sessions.
I'm wondering who has more say, Google or the individuals on the core Go team. My guess is that said people's personal opinion matters a lot more, or rather, almost exclusively.
How exactly would "Google" decide what goes into golang? They pay the Go team to do that, and I have a gut feeling that the Go team will do what the Go team wants to do, and not something else.
I would also be surprised if enough of them didn't have a sufficient amount of "fuck you money" to be able to effectively do what they want even if Google somehow managed to find someone who feels like they have any authority to tell the Go team which way to go (pun not intended).
This isn't a case of an evil empire seeking to enslave our minds via a programming language; it's a company open sourcing their internally designed language, and engaging the community to make it more useful outside of Google (and to increase the number of people who use the language, which is always good because it means a greater pool of developers who could possibly work for them).
None of this is inherently bad or good.
This seems rather misinformed. Go has a spec https://golang.org/ref/spec and at least 2 alternative compilers in the form of gccgo and GopherJS.
I'd love to hear where do you base the notion that Go's stakeholders do not appear to value standardization of the language.
In general technical use, standards and specifications are different. Standards are technical documents published by an independent standards organization. For example ISO in the case of the C programming language and ECMA in the case of ECMAscript (i.e. Javascript). Standards (in conventional use) have formal processes for establishing stakeholders, submitting proposed changes, acting on proposed changes, and publishing changes to the standard.
Formal processes are not an inherent property of specifications. The Go specification could change in surprising ways tonight. Though it probably won't. The process for changing the Go specification can also change. Specifications are short lived. Standards are 'forever'. Fortran 77 is still Fortran 77 because of X3.9-1978.
It is common for specifications to incorporate standards by reference. For example a specification might include "the program should generate valid XHTML 1.1." The standards body W3C provides a process for determining conformance with the standard https://validator.w3.org/. T
Can we keep the discussion substantive?
Go is just like many Google projects and Google "community" programs. They are basically a way to get free labor while benefiting Google first and foremost. That is a philosophy that goes right up to the top. Yes others benefit from the free software, and by fixing something you might be scratching your own itch, but if you invest any unpaid time towards developing for it you need to understand the Google controls everything (unless you fork it).
If you get on the wrong side of the Google activists, they will use the COC to invent a reason to kick you out of the main project. Some of Google's "community" programs are not as subtle about things. IE: The Google Developer Expert program in these "community" technologies such as Angular, Android etc. require the unpaid developer experts to sign non-disparagement agreements with Google while in exchange only getting a little bit of notoriety and a few comped trips and tickets to events...and of course Google is the gate keeper for it. The GDG program is even more flagrant. Each chapter is "independent" and has to raise their own money for things, but then Google tips the scales by throwing money towards programs that shill certain Google products. Google also has guidelines on how you market etc. things and is able to be a gate keeper on who is and isn't and organizer etc..
Many of the Google "community" "open source" packages are first only released to people under NDA's. I've seen this happen a few times with the some of the Android libraries etc..
Does that mean that Go is bad? No, in the same way that proprietary technologies are not bad. The key is understanding the truth from the propaganda.
I haven't heard of this. What's the rationale?
And say, they still wanted to lead the project? Even though they no longer work? Could they? Or would Google appoint new people, and maybe Go would lose its magic?
I guess that's the difference between run by one or a few BDFLs and run by Google?
Well, not if people in the Go community can't be promoted to be among "the final deciders about the language itself" without also being hired by Google.
Sure, the community is 1 million people. Nobody expects 1 million people to vote for Go's design and features.
But each language community develops prominent members, which for Go can be outside of Google too. E.g. like JS had Resig and Askenash, or Java had the various Java Apache project leads, Yoda time, etc people, or like Python has Kenneth Reitz, Armin Ronacher, the Twisted/Tornado guys and co. And some major projects, modules, etc, eventually emerge.
If those people can't get their (widely adopted by many in the community) proposals and changes into the language, and don't get the chance to be core team, them it's not a community language.
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.
Senator: "Mr. Mayer works for you, does he not?"
Mr. Hughes: "He does."
Senator: "And what is his official title?"
Mr. Hughes: "Well I don't exactly know, Senator. A lot of people work for me."
Senator: "Explain why your press agent would pay out $170,000 to representatives of the United States Air Force."
Mr. Hughes: "Well I don't know, I suppose you'd have to ask him, Senator."
Senator: "Well would you produce him?"
Mr. Hughes: "Produce him?"
Senator: "Will you cause him to appear?"
Mr. Hughes: "Senator, you had John Mayer on the stand for three days last week."
Senator: "Well be that as it may, we would like him to reappear. Would you ask him to return?"
Mr. Hughes: (long pause) "No, I don't think I will."
Senator: "Will you try to have him appear?"
Mr. Hughes: "No, I don't think I'll try."
Senator: "You don't think you'll try..."
Mr. Hughes: "No... I don't think so."
In other words, go fork yourself, Senator.
