Highlight: Stop submitting patches to Guava - it is too much work for us. My Favorite response (from Martijn Verburg): "...could you guys work with the community to teach them to submit better proposals/patches? Many open source projects are able to do this from the Linux Kernel through to hobby projects like PCGen. Perhaps talking to their committer teams might give you some insights."
Interestingly I heard that the Java people at Google rail against using Python for large projects because they supposedly get out of hand..
The story of Google Guava and patches
21–30 of 50 posts
Re: The story of Google Guava and patches
#22I'll call bullshit. Either they care about external developers or they don't. This is saying they don't. Google's culture seems insular and elitist. Besides Guava, they did the same thing with GWT (which, as much as I love GWT, didn't work out in the project's best interests, IMO), and now are doing the same thing with Dart (AFAICT). Maybe in the 90s you could get away with this. But now if you don't have an active e…
Sadly, Kevin doesn't sound too good here:
And here's the last thing. Be honest: if you were going to sign yourself up for doing all that work above... wouldn't you at least want to have the pleasure of writing the code for it yourself?
Code is code. (Well, as long as it's not awful/ugly code.) I'm as happy to marshal through someone else's code as write my own.
Re: The story of Google Guava and patches
#23Sure it's great people are excited and want to contribute but all that excitement is due to the love and care people sweated in to making every single line in that codebase as perfect / performant / easy to understand as possible.
Patches almost never add to something like that. ESP not on such a small focused library. Truth be told most of the time on open source projects you're accepting patches simply to get more community involvement and acceptance. Guava doesn't need acceptance, it has been lovingly accepted already. If you want open armed love go to apache commons.
If you want perfect performant code you can use and trust consistently go to guava.
I'm grateful and happy that it exists and it is a pleasure and delight every time I incorporate a little bit more into my codebase, slowly.
Re: The story of Google Guava and patches
#24I'll call bullshit. Either they care about external developers or they don't. This is saying they don't. Google's culture seems insular and elitist. Besides Guava, they did the same thing with GWT (which, as much as I love GWT, didn't work out in the project's best interests, IMO), and now are doing the same thing with Dart (AFAICT). Maybe in the 90s you could get away with this. But now if you don't have an active e…
Not all of Google is that way. The Chromium project, I think, is a notable exception. Gerrit Code Review is happy to accept outside contributions. And technically the Git maintainer (Junio Hamano) is a Google employee these days. Sadly, Kevin doesn't sound too good here: And here's the last thing. Be honest: if you were going to sign yourself up for doing all that work above... wouldn't you at least want to have the…
Don't even get me started on what I think about accepting or submitting patches for code I don't actually plan on using on a day to day basis.
Re: The story of Google Guava and patches
#25It seems there is open source which is setup for community contribution and open source which isn't. We tend to only really think of open source, ideally at least, in terms of projects that allow community contribution. From what I have read Android is pretty similar? Very hard for developers to actually get some of their code merged. Wondering now what other Google projects are like for outside contributions, Chromi…
Very few Google projects allow outside contributions. Go is one that does; no surprise there of course. There is an attitude pervasive at Google that open source is a great marketing tool, but that it's a one-way street. I think it's because of the high employment standards at Google; they cannot fathom how someone without an @google.com email address can do better than them. Dart is the perfect example of this: deve…
First, plenty of Google projects allow outside contributions. There are over 1400 open source Google projects (The number is actually much larger, but i've only counted those that wanted to be identified specifically as Google projects), and >98% of them allow contributions the last time I looked. In fact, it's easier to simply list the ones that don't than the ones that do. I have to imagine you have your own list of what you think are "Google projects", and are working off of that when you made your assertion.
Second, there is definitely no "attitude pervasive at Google that open source is a great marketing tool, but that it's a one-way street". As the guy generally responsible for helping teams that want to open source stuff, I can tell you that in 6 years, I've run into this attitude maybe 5 times out of the (again) 1400+ projects that got released. That's not to say everyone open sources stuff at Google for the same reason, but there is certainly no pervasive attitude like you describe. The reality is a lot of folks at Google have released open source projects for a lot of reasons, and of those reasons, "marketing tool" is pretty far down the list.
BTW, none of this is to say I agree with Kevin's approach to running Guava; I don't, for various reasons. But in the end, he (and the rest of the guava folks) are the ones doing the work, and the issues here will work themselves out in the normal way (either people will grudgingly accept it and keep using guava, or some fork will become more popular eventually and take over). In either case, Kevin making a clear statement on the situation helps move things along one way or the other, and is a lot more than you can get out of other OSS projects that do something similar.
Re: The story of Google Guava and patches
#26Am I the only one who is really annoyed by links to Google+ that can only be seen after signing in? I thought it was considered bad style to do that for NYT links here. Maybe the same holds true for G+ links?
Re: The story of Google Guava and patches
#27Re: The story of Google Guava and patches
#28Highlight: Stop submitting patches to Guava - it is too much work for us. My Favorite response (from Martijn Verburg): "...could you guys work with the community to teach them to submit better proposals/patches? Many open source projects are able to do this from the Linux Kernel through to hobby projects like PCGen. Perhaps talking to their committer teams might give you some insights."
Interestingly I heard that the Java people at Google rail against using Python for large projects because they supposedly get out of hand..
Re: The story of Google Guava and patches
#29Am I the only one who is really annoyed by links to Google+ that can only be seen after signing in? I thought it was considered bad style to do that for NYT links here. Maybe the same holds true for G+ links?
This post should be publicly visible without being logged in (at least it is for me). But this is the second HN thread in a week where I've seen a comment like this, so can you send me your details (web browser, etc), so I can debug, please?
Re: The story of Google Guava and patches
#30I'm usually won over by them because Google does truly great Java API design, their releases are relatively high quality (there is some assurance of quality when it's used internally at Google) and their libraries almost always enforce good design (they don't accept things that you would consider helpful if they think it will be easy to use incorrectly or abuse).
But with that comes the bad. If something's not helpful to Google, it won't have sponsorship to be added to the library. The library will always support only versions of Java that Google internally uses (Kevin has said before that it is unlikely that Guava will be expanded to cover even Java 6 any time soon).
So I'm enjoying using their libraries while they are current, but am fully aware that they might need to be forked eventually.