The story of Google Guava and patches

I'll call bullshit. Either they care about external developers or they don't. This is saying they don't.<p>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).<p>Maybe in the 90s you could get away with this. But now if you don't have an active external community, whenever your old guard of Guava/GWT/Dart developers gets bored and leaves, the new guys that come in behind them aren't going to care nearly as much about the Google internal technologies vs. the true open source technologies they've been hacking on before/after their time at Google.<p>So the Google/internal technologies will eventually stagnate.<p>Perhaps internally-driven projects can get more stuff done in the short term (thanks to dedicated resources), but I think in the long term the external community out-innovates internal projects (due to the internal teams getting burdened with legacy requirements (<i>cough</i> GWT), politics, etc.). Dunno, that's my impression.

Highlight: Stop submitting patches to Guava - it is too much work for us.<p>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."

Maybe I'm alone in thinking this but having been in the position of reviewing more than a few non-trivial bugfix patches myself I think I might tend to agree with Kevin.<p>Sure 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.<p>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.<p>If you want perfect performant code you can use and trust consistently go to guava.<p>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.

A rebuttal: <a href="http://rethrick.com/guava" rel="nofollow">http://rethrick.com/guava</a>

Am 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?

You really have to take the good with the bad when it comes to Google sponsored libraries.<p>I'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).<p>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).<p>So I'm enjoying using their libraries while they are current, but am fully aware that they might need to be forked eventually.

The point that seems to be missed here is that Google is eating their own dog food. Doing such they are hesitant to fix what "ain't broke." Were this merely code that was being thrown over the fence from time to time I'm sure you'd see a higher patch adoption rate.

It 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.<p>From what I have read Android is pretty similar? Very hard for developers to actually get some of their code merged.<p>Wondering now what other Google projects are like for outside contributions, Chromium etc.

tldr: It's more difficult to maintain a Java util library than it is to maintain the Linux kernel, so patches are not welcome. They'd love the community to do their bitch work though.

a better point is the preface to the guava project docs:<p>"The Guava project contains several of Google's core libraries that we rely on in our Java-based projects"<p>given that, it is fair to say "this is essentially an internal codebase, and we would prefer to develop it ourselves so that it fits our internal practices and standards; however, it is an extremely useful set of libraries, and we are happy to share it with the open source community so that you can use it too, if you like"

Sounds like a good article, wish I could read it on my mobile iOS device.

Branching.<p>A simple feature everyone is trying to avoid, but sometimes it's like am open door from golden cage.<p>Guava is the "from inside out" project presented as "take it or leave it". I would not personally beat Google because of their attitude towards changes. But they have to state it explicitly, otherwise more contributors - after so much work they invested - will feel betrayed!

&#62; <i>If the change touches on any existing functionality, we have to submit it to Google's global submit queue and analyze test results from many thousands of projects to make sure we won't break any internal users with it.</i><p>Is there any public info about "Google's global submit queue"? I would love to learn more about such a huge automated test system.

Guava is a work of art created by the team that maintains it; what's the big deal if you can't add your own code to it? Merely a lost opportunity to advance your own vanity?<p>Respect their boundaries and let your experience inform your feedback to them. If you read what Kevin is saying, it is clear they are interested in hearing if, how, and why their library is helping or hurting your own project. They will probably listen if your feedback provides the answers they seek.

The hard part of guava is deciding what to include and exclude and they base those decisions mostly on what is useful at Google. The code is easy and handing them a patch is pointless.

"Sam Berlin - Disclaimer: I don't know what patches to the Linux Kernel are typically like, nor PCGen. But, +Martijn Verburg, there's a pretty big difference between submitting a patch to a library and submitting a patch to a "project". Patches to libraries are typically changes/additions/removals to the API, whereas patches to 'projects' are typically changes to the internals. It's a whole lot easier to change the internals of something than it is to change the API. Changing the API means the effects can bubble outwards. Changing the internals is usually just optimizations or bug-fixes."<p>haha wow. this is why I love java programmers

The simple solution for dealing with Google-scale bureaucracy is to fork and continue pushing forward. Then when that fork gets locked down, create a new one. Not every project is going to be bureaucracy impaired, but there is a correct procedure when it is. Multi-round "grueling" code reviews, and API review meetings? W.T.F.

Java is stupid.

Guava is one of the best Java libraries available today, and the fact that the bar for submitting patches is so high is a simple consequence of that.<p>You can't have it both ways.