Shared publicly  - 
 
(If you don't use Guava, you can skip this...)

The story with #guava and your patches

Guava users,

Many of you, when you request a feature for Guava, have submitted a patch to us with the implementation (or even pasted code directly into bug reports).

And we have almost never accepted any of these patches, let alone even read them. And I know this makes us look all manner of self-absorbed, arrogant and unappreciative. That's what I'd think in your shoes. So it's time I tried to explain to you more fully why it's like this.

I realize that from your perspective, you're handing us a shiny new feature on a silver platter. It should be making our decision easy, since the work is already done. It's a gift of your time and effort and you've already solved the problem and all we need to do is just accept it! Looked at that way, we're either idiots or jerks for not being interested.

But here's the part that I don't think many of you understand: the work you've done to produce that patch is actually minuscule compared to the total amount of work we have to do to put it in Guava. I know that it feels to you like you've certainly gotten us more than halfway there, but trust me, it's only scratched the surface.

- We have to work out whether the problem it's trying to solve is truly the right problem
- We have to work out whether the solution presented is truly the best solution we can come up with
- We have to find evidence in the internal Google codebase that users will actually use the proposed feature if we create it. If we are adding methods to our libraries that don't get used, it hurts our case when we try to argue to management that we're doing important work and need more staff.
- We have to figure out how it relates to the piles of legacy code we have floating around our libraries (that you, lucky folks you are, don't even see!), and how we would deal with migrating those users if they exist.
- We have to decide the best name and location for the new API. This is hard! We spend a lot of time in our API review meetings just batting names around.
- We have to review the code deeply. Our code reviews are grueling and go on for many rounds. When you look at the code in Guava it tends to look "obvious", but we work very hard to achieve that quality. It's only obvious in hindsight.
- In almost every case we have to completely rewrite the javadoc that first gets submitted to us. And this is very hard. Writing good documentation is probably the biggest challenge we ever face.
- The tests that were first written are rarely sufficient; we're going to need to add more. When we do, some usually fail.
- 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.
- If the change goes in, we have to deal with the machinery that gets that change integrated out to you in Guava.
- We then become responsible for fixing any bugs with it that come up over time, and dealing with the related feature requests it will touch off.
- And the code never "stays finished' in general; we are constantly performing various maintenance tasks over our whole library (or even the whole codebase of Google), to make various cross-cutting improvements, and every bit of new code added increases that burden.

There's more I'm leaving out, but you get the idea. Guava did not get to the level of quality it has by accident, but by us being really obsessive about these things.

Now, when the patch comes from outside Google, we have additional mechanical overhead. One of us has to sponsor the patch as if it's their own, converting it into an internal patch that can merge correctly (which isn't always as trivial as it sounds), and sending it for review to another member of the team. And because we are the ones most familiar with our own style, conventions, practices and pitfalls to avoid, etc., sometimes just doing that plus "cleaning up" the code to get it ready for review is already more time-consuming than if we had written it ourselves from the start. That doesn't even mean that the code sent to us in the patch was bad. It can be very good by most standards but still need a lot of rework for our purposes.

Remember, if your feature is valuable, then we're going to want it in Guava whether you provided a patch or not. Providing the patch doesn't make it more likely that we'll decide it's a good fit for Guava -- if anything it just puts us more on guard against that seductive temptation to think "but it's already mostly done anyway, might as well!"

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? I love writing code -- that's why I do this! -- but such a large majority of my time goes into activities like those described above. If my job were all about just applying other people's patches, I would inevitably start hating it after a while. Let me have some fun sometimes, okay? :-)

I really hope this helps to understand why your patches seem to go into a black hole. I know that no matter what I say it will probably continue to seem unappreciative and condescending, and I apologize. I do recognize that you are just trying to help. But, if you really want to help, then keep an eye out for the times when we will ask for help on a particular issue, because that's where your time and energy will really do the most good!

Rantingly yours,
KB
86
46
Steve McLeod's profile photoSven Strittmatter's profile photoBill de hÓra's profile photoAditya Varun Chadha's profile photo
68 comments
 
Thanks for this explanation Kevin, like some of the things you mentioned it's obvious in retrospect but this helps a lot more. Oh and thanks to you and the other Guava guys for your efforts, I certainly appreciate it.
 
Tl;dr version: Stop submitting patches to Guava.
 
I think few people realize how much work can be involved in accepting patches to an open source project that's in heavy use, especially when the code has a large API surface area.
 
http://www.producingoss.com - I humbly suggest that there are many other projects in the same boat, yet a number of them manage to 'teach the community to fish' - perhaps the Guava folks could start a programme on that.
 
Maybe there needs to be something like StrawberryGuava - a place to put new and interesting bits of Guava that aren't part of the core. With no promises that it's an incubator or anything like that, just a collection of community additions, not managed by the Guava team.
 
So basically, Google's internal use of Guava is more important to the library's maintainers than the external users.

As the owners you guys are of course free to choose that, but this attitude makes using Guava less desirable.
 
You may underestimate how much work it takes us to even keep open-sourcing the code at all. Dealing with moe and maven sucked a huge part of our last quarter into a black hole. We care a lot about serving all our users, and if taking external patches were an effective means to actually making the library better, we'd do it, but it just isn't. Sorry!
 
So I ask again - 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.
 
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.

I suspect Kevin & folk would more easily welcome non-API changes to internals (disclaimer again: I don't know), but from what I've seen the vast majority of bugs/patches to Guava are for new APIs. Those are just a lot harder to deal with. The lack of "internal" patches is a great sign that the library as-is is pretty darn good at what it does.
 
.. and, just to follow that up: Changes to Guava are even harder to take than most other library-like projects, because Guava's sole purpose is, "Expose an awesome set of APIs that make your life better." Doing that well means making some hard choices & cutting lots of halfway-decent APIs, leaving only the real winners that let your code shine. I don't always agree with some of the decisions in Guava, but I do know that Guava is better because of what it leaves out, and not what it includes.
 
I think people will feel better when I write up a long list of all the ways in which the community really can help Guava in a useful way. It's only that "sending us implementation code" just isn't one of those genuinely helpful things; that's just not the kind of library we are. Implementations are almost always easy relative to the rest.

The fact that that (code patches) was the only subject of my post here created an overall impression for some readers that Guava just doesn't need help from its community at all, which is wrong. Sorry!
 
I can admin that a large percentage of submitted patches is not relevant but that this percentage is 100 seems to me a little short minded. How many Guava commiters are not Googlers ?
 
it's not 100%. But at its core, Guava is a Google project.
 
Note also that a huge proportion of the complex issues have to do with API. Patches that fix some bug or performance problem are a different story indeed. I didn't think to mention that because we get those rarely compared to people wanting to add more methods and classes to the library.
 
I also feel we could be engaging the community better (and I agree than in most cases, the code is the easy part, comparatively).

Here's an idea. When business pages come, we should have a guava page, and we could be announcing interesting ongoing stuff there. We had a ton of api discussions; we could be more open as to what our thoughts are, and one of the best ways is what +Kevin Bourrillion occasionally does at guava issue pages; copy-pasting a snapshot of the API to come. I wish we had a more central, visible place to do that, and we did it more often, including a brief mention of important use-cases, and hopefully induce some deep thinking in the community. So, why not here?

(We should make it, and mention it in the mailing list, and heck, and add a boilerplate link like the one to stackoverflow)

Of course that would involve yet more work, but it's also work of the fun kind, so, I'm looking forward to it :)
 
I might misunderstand it but this reads as if Guava is not an open source project but merely a project with freely available source code controlled by a single company (Google in this case) ? I think it is misleading to conflate that with the arguments about high quality codebase and in-depth reviews as those can be achieved just as easily by community-driven open source projects (see e.g. apache httpd, linux kernel, rails, ...) when it seems to be more an issue of control over the codebase and direction that the project takes.
 
Well, there is the fact that we take all of our source code, put it out where you can have it, with an Apache2 license on it giving you leeway to do almost whatever you want with it. If that's not enough to be called "open source", I don't mind if people want to say that Guava is not open source.
 
Don't get me wrong, there is nothing wrong with wanting to be in control of the library, esp. if it is important to the company. But claiming that you can't accept patches because of the high maintenance cost is imho misleading, other projects do that just fine by accepting members of the community at large that have proven to be reliable. If you don't want a community, then great, but in my opinion at least community is what makes an open source project.
 
The thing everyone's overlooking is that if there is a feature requested where we've made the decision that we do want the feature in Guava, enough that we work out all the details of where it should be and how it should be named, etc., and if we can see that we actually save any time by asking for users to contribute a patch -- then we do that, and we take the patch. That is a relatively new development, but only because until we moved to git we didn't have the proper machinery in place to make accepting an external patch even a reasonable process at all.

We want you, the community, we just don't want your code, and if that sounds harsh, I'm just going to say for the umpteenth time that you may be greatly overestimating how important code is to Guava. Code is the easiest part. A detail. Don't sweat it.

Once again, I pledge to write up some useful information on how to actually help Guava -- and even how to sell your idea to Guava's maintainers. There are certain arguments that really "push our buttons" and make us want your feature, and we'll lay that out for you plain as day so you can use it against us. :-)
 
Quick anecdote to illustrate why it needs to be hard to add code to Guava.

I was doing a code review and my co-worker had added a Predicate that tested for reference equality. The second I saw it, I said to myself - the Predicates utility class has to have its own reference equality predicate. I looked and it wasnt there.

I asked my co-worker to ping the java library discuss group and ask if there was
a reason it wasn't there and if - not could he add it.

Kevin quickly responded that the library used to have it, and the majority of places where it was being used could just as easily and correctly use .equals() instead so they removed it from the core library.

So here we have a valid/useful feature that when it was a part of the core library was frequently improperly used.

Leaving it out of the library was 100% the right call.

Kevin and team are making judgement calls on what makes up Guava based on use cases from hundreds of projects. This is why the library is so good. Most people (myself included) are mainly thinking from an individual project perspective.

The best way to contribute to guava is to tell them your problems / ask for features / etc. (And of course catching bugs !)
 
+1 to that. Contributing use-cases is gold, probably the best way to help guava. (Digging for use-cases is hard work, even when all the code is available)
 
+Kevin Bourrillion War stories a la +Thomas Knych 's on how internal guava patches for the API surface are progressed would be awesome and help enormously in understanding why it's a big deal to have strong upfront controls on the library. IMO you're right to be cautious - libs like Guava (or Guice) live at the very bottom of the stack and it's incredibly hard to elide an invalid design at that level. I've pretty much stopped using chunks of java and jakarta/commons thanks to Guava and am more than happy to see a benevolent dictator model. I'm guessing documentation and/or test cases would be more welcome?
 
Oh my goodness! Yes, we all know you at Google™ are the very best coders of the universe and Google™ produce the best code ever and we others not at Google are all stupid idiots ;) I do the work you mention all the time at work, too. Guess what, that's what I paid for as software developer, not only for coding ;) If you don't wanna do this: Stop crying that you need to convince management and don't put the code open source ;)
 
Kevin: It's really not that Guava don't accept patches that's frustrating. It's the that the Guava team claim to accept patches, but then don't follow up by even commenting on submitted patches. It can come across as a rather rude.

Consider OSGi support: an issue was created, you said yourself you'd accept a patch for it [1]. The issue was marked as 'Fixed' without ever actually being resolved. Instead a separate project, guava-osgi, was created. It had p2 repository with volatile artifacts. It seemed crazy that people who work in a company with as much QA as Google didn't appreciate the problems that artifacts changing under your feet can cause. There are a variety of other problems also explained in the ticket; but these arguments fell of deaf ears.

So, over the course of three or four years, with as many patches, and several attempts to explain the problem, no one would explain why the patches weren't sufficient. Just trotting out the same line of "use guava-osgi", without addressing the problems with it.

You say "if your feature is valuable, then we're going to want it in Guava", but the reality is a slightly more disappointing "if your feature is valuable for Google, then we're going to want it." Now, I can't fault Google for not wanting to invest time in technology that it doesn't use, but please don't pretend the project is something it's not.

[1] http://code.google.com/p/guava-libraries/issues/detail?id=64
 
Out of curiosity, you should ask the GWT team how not fostering an external dev community has worked out for them.

Your post sounds exactly like something the GWT team would have said from its founding up until ~3 months ago. AFAICT, their insular approach to development may have worked great for Google's internal usage/adoption of GWT, but it sure hasn't helped its external acceptance and, IMO, long-term project health. To me, it is a big reason why GWT just hasn't been fast/sexy/good enough to compete with the latest front-end technologies that non-Googlers actually use.

Note that I say all of this as a huge GWT fan. However, I want GWT to be more awesome than it is now, and I'm pretty sure it would be if 5 years ago the GWT team hadn't been as internally focused as you're being with Guava. Would hate to see you guys repeat their mistake.

Yes, Google engineers are awesome, and full time employees can get a lot done in the short term. But in the long term, external contributions from guys who really can work on whatever itch they want instead of whatever they can justify to their boss (like you right now), can make a big difference in the long-term quality/relevance of an open source project.
 
What I find surprising is that nobody has noticed that this is consistently how Google projects that are used internally have always functioned. Out of any other corporate entity that dips its toes in open source waters, Google is bizarrely obsessed with NIH, even in this day and age.

Open source at Google is not a strategy, it's a marketing gimmick, and a cold calculated move. In other places it might be 'this is not our core offering, so we can gain from the open source model'. At Google it's more likely to be 'this will earn us some good PR, so lets slap an open source license on it and dribble out patches based on developers whimsy'.

Google Guice is another example, which has always refused any patches or attempts at integration with the rest of the Java ecosystem (until somewhat recently). The response always was 'we don't need it at Google, therefore it will not go in'.

I appreciate the minimalist approach, and I certainly sympathize with it when one is burdened with the knowledge that it is very unlikely that there is anyone outside of Google who has anything intelligent to contribute. Perhaps there needs to be a clear disclaimer applied to this sort of 'open source'. Find a polite and catchy term to describe the 'shit we throw out for PR and pretend it's open source' sentiment and slap on that label instead.
 
I am finding the idea that Google calculated we should release Guava as a PR move to be endlessly entertaining, thank you.
 
why not just fork and forget the original? or is that against the license?
 
"wouldn't you at least want to have the pleasure of writing the code for it yourself", can we get this quote in the next textbook on software engineering anti-patterns? ;)

Having people submit patches helps in getting the code right, it's not about who writes the code. I'm not saying you should accept any patch as a whole, you can choose to use bit and pieces or just look at the code and use some ideas.

That said, I do appreciate an honest blog post like this.
 
Kevin, thanks for this helpful explanation. Thanks also for the work you and your team do to make sure Guava is available to us as open source. I've learnt things by reading the Guava source and my own code base has benefitted.
 
+Hani Suleiman You're so rigth! Google never did any open source and the mosty didn't realize that, because they're not evil... It's a sham to put the code for free use into the internet, but didn't accept any participation. Shwo me the last community patch integrated into the "open source" android project egg
 
Wow, there couldn't be any more powerful argument to convince me to never use this library. Testing, code review, documentation, these are all part of software development... to actually be an open source project these must be community activities too, not internal google activities.
 
I'm pretty sure you just shattered whatever community you may have had. OSS is not about internal company politics. Its not about showing how awesome the code your company produces is.

It's about sharing the responsibility for a project with a community rather than limit ideas to any one company. If you (google) really want to play in the open source space, fix your internal patch acceptance mechanisms.

We just did this for the Scala project and the community has stepped up and started helping us out. By not accepting patches, you aren't just appearing arrogant, you're being arrogant. Those other issues are no real excuse.
 
Kevin, my comment that Google releases OS as a PR exercise is from an ex-googler: http://rethrick.com/#guava

'Google Wave for example, treated open source as a second class citizen, a marketing gimmick and a once-made promise to be kept, time allowing. Guava seems to be bleeding those same colors.'

I realise for you (and other engineers) it's more than that, it's something you feel is a genuine contribution (and it is, I don't want to detract from that) to the Java community at large. I even agree with the 'benevolent dictator' model you have. My issue is more with the fact that the benevolent dictator is not actually benevolent, instead it's 'If what you propose is not going to be useful to Google and fits into its own model, then don't even bother talking to us'. There are any number of examples where huge armies of people have agreed that something is useful, but is not accepted because it's just not something useful to Google. Case in point,@PostConstuct for Guice, where the official response is 'we don't need that shit, so go create your own subproject so our code stays our code'.
 
While the license is open source so thus technically that makes the project open source, this behaviour definitely reeks more of a cathedral rather than the bazaar that is important to the open source community*. This also reminds me to how Apple used WebKit but would only release complete releases and not individual patches so that the KDE team found it too difficult to integrate their work. Frankly, I'm just now consider Guava to be an internal Google project that they are sharing with us rather than a community open source project.

* If the reference is lost on anyone then you have bigger problems.
 
I understand the constraint, the best approach would be to create a project something like "raw guava" where all these new patches and features could get submitted, upon sufficient maturity and satisfying all the constraint that Kevin mentioned, they could be assimilated in "ripe guava". This I believe is the most logical solution in this case to go forward.
 
Apologies if my comment earlier wasn't clear: the current approach is fine.

The problem is when developers ask for patches, then stating they won't be read once they're already submitted. A simple note to say "thanks, but we're no longer interested in progressing this issue at this time" would be polite.

It'd save time for Googlers and prospective contributors, rather than discouraging other forms of contribution.
 
Everyone, thanks for re-invigorating this discussion. :-) The team is listening to and reflecting on everything you say. I see now that we really have some problems to fix.

Everyone who cares about this issue, please follow +Google Guava, where we'll continue this conversation as soon as we can. (At that pont it probably won't make sense to keep comments open here anymore; comment threads (especially unthreaded) have natural effective lifespans.) Or, if you don't want to use Google+, I'm sure that once we post there someone you're following on twitter will tweet about it. :-)
 
+Martin Ellis The submitted OGGi patch did not work, and we posted as much on the bug report... but I see now that there were two separate bug reports that we failed to merge, so half of you are in the dark :\ My apologies for the trouble. I've merged the two.

Please do let us know if there are other specific patches that are sitting idle.
 
+Chris Povirk Not sure which patch you're talking about. There were four patches for OSGi in issue 64. I can only find a reference to the one in 688 not working. I didn't see any feedback on mine.

The patch in 688 is most recent, so hopefully that will get fixed for 12.0.0 as per your comment on that ticket.
 
+Kevin Bourrillion Did we ever generate the promised "long list of all the ways in which the community really can help Guava?" If I can go a calendar month working on Guava without submitting a CL, then I'm sure we can find ways for others to do the same.
 
Responding specifically to the points I made that +Dhanji Prasanna called out: I find it a little disingenuous of Dhanji to compare patches to the Linux Kernel and patches to Guava as the same thing. Dhanji's a nice guy, no question about it -- we've worked together on Guice -- so I'm wondering if there's another reason for stirring up an old hornet's nest.

Specifically to the Linux comments: The Linux Kernel has a wide berth, there's hundreds of millions of things that can be changed/fixed/tweaked inside of it, none of which are anything like changing a public API. I think the barrier-to-acceptance is much lower for patches to Linux that are purely tweaks to internals: optimizations, fixes, tweaks, etc.. If patches that modify, delete or introduce public APIs don't go through more scrutiny, I'd be shocked. It's disingenuous of Dhanji to conflate all patches to Linux as one type: modifying an API. The Kernel exposes an API, but there's a million things inside that Kernel that aren't part of the API.

Libraries like Guava or Guice are different than "projects" or "programs". Their sole purpose is to expose useful APIs to a developer to enable them to do things quickly. Read that again: enable developers to do things quickly. The more surface area an API has, the harder it is to figure out how to use it, so it's only natural that a part of achieving that goal is limiting the API.

Dhanji mentions that Guice accepts patches from the open-source world and praises it, but with the same hand he condemns Guava. This is expected, as Dhanji happens to have written two of the extensions shipping with Guice (servlet & persist), so the naturally there's less contempt for Guice. In reality though, there's very little difference between Guice & Guava. Both have a limited set of contributors. Both have a very tough stance on new APIs (Guice even more-so). Just see the comments above with people complaining about rejecting @PostConstruct from Guice... there will always be APis that folks want that won't make the cut.

The goal of a good library is to enable developers to do things quickly. It's not to give a developer every single API they could ever ask for and force them to wade through them all to find the right one. You give folks what they need and no more, and you guide them through how to use. If others want to build extensions on top of the project, please do! You can easily add @PostConstruct into Guice using the SPI it provides.

I'm sure Kevin will clarify his thoughts, but my take on it (and the same stance I use with Guice) is very simple: introducing new APIs is easy for submitters, but can be terrible for users, the library, and maintainers. Most folks submit patches that introduce APIs. The fact of the matter is: that's going to have a much harder time being accepted. Submit all the patches you want that don't introduce APIs or change behavior, great! But when a library is serious about being useful to users & maintaining a low surface-area: the less APIs there are, the better.
 
Of course it's disingenuous, since guice suffers from the exact same problems (because it's the exact same holier than thou crowd that's involved in both, or at least there's a lot of overlap). No doubt he feels guice is 'better' because it accepted his tangential and unrelated patches to guice core, despite rejecting many other patches with a similar theme (namely, better third party integration). Of course, I'm sure that had nothing to do with him working at Google and being part of the in crowd, and instead was purely about the quality of the code and how it was a natural fit to Guice's core mission.
 
+Martin Ellis Hmm, some others on the team have been following this more closely than I, and I hadn't realized there was more than one Maven OSGi patch. I don't know why it wasn't tested; maybe the others on the team had forgotten it, too, by the time we discovered that the guava-osgi version was broken, or they expected to hear back from the guava-osgi maintainer sooner, or this was just another victim of our failure to merge the bug threads? We should have pushed forward on this, one way or another. I just went to apply your patch, but now I can't reproduce the submitted patch's problem that my teammate was seeing earlier. I've posted on http://code.google.com/p/guava-libraries/issues/detail?id=688 and will continue to update there as I find out more....
 
It seems to me that much more attention has been spent on Kevin's post than on how Guava actually works. We do in fact accept external patches. We do in fact have avid externel contributors to our mailing lists and issues database. Our big weakness is dealing with issues which only impact external users. That's something we're struggling to figure out. But we're actively working on it, not blindly ignoring it.

If something's bothering you, or you're not getting the turnaround you expect on an issue, just drop us a line at guava-discuss. Sometimes something gets lost that really needs to be dealt with. Just say so. Help us understand how bad things are for you.

Complaining about the lack of community is a pretty weak substitute for taking the initiative to actively participate.
 
I don't understand the brouhaha over this issue. As long as Guava's code stays open-sourced, you can mirror the code tree internally in your project & make local changes. To google and +Josh Suereth thank you.
 
+Gangræna Gorgeous I can't tell what you mean by that, but if you're suggesting that you have a fix for bug 776, we'd love love love to see it. I was unable to even reproduce the problem without the help of the community, and I've been playing with jar changes and compiler-arg changes to no effect :(
 
Ah ok, so the answer is: go write docs, work on things we want fixed, or evangelise what we've decided to do!

The list is 'how to contribute to open source if you are unable to write code'.

Sorry Kevin, I like you and all, but that post further cements the 'please stop trying to give us code, if it's not written by us we're not interested' perception that people have.
 
Wait: the basic fact that code is very rarely what Guava really needs is not a "perception", that's the actual exact point I am trying to make in this post. I can't help people being annoyed by that; it's just a fact. Code is the easy part, by far.
 
To the extent that that's true, I would rephrase it as: "Please stop trying to give us code. Even if it's written by us, we're not interested." I just looked at my last 200 CLs, dating back to October, to find new features I've added. Two CLs added GWT support, one changed Futures.chain to Futures.transform(..., AsyncFunction), and one loosened the type signature of hasContents*Order. That's the closest thing to a feature that I've added in at least five months. I recommend glancing at the list of recent changes to see what code ~5 full-time engineers can produce. (Also notice that, of the 25 changes listed now, 5 are from an external contributor, and at least 4 more[*] address publicly reported issues.) Nearly all the concerns in Kevin's original post apply equally to those of us who work full-time on Guava. And those that don't, like the mechanical overhead of patching, I don't think have ever caused us to turn down a patch, despite Kevin's concerns that they would. In short, most of our team's changes do things like remove deprecated methods and add tests, and historically most provided patches don't do these things. Nor should they have to: Part of our role as full-timers is to do a lot of grungy work.

(None of this takes away from the problems we've had with OSGi and surely other issues, and I'll continue to try to address specifics as they come up.)

http://code.google.com/p/guava-libraries/source/list
[*] FluentIterable, MediaType whitespace, primitives toArray(Collection<? extends Number>), AbstractLoadingCache Javadoc links, plus the already-counted AbstractMultimap.put change
 
What many also don't realize is that in those few cases when it looks like we just wrote a bunch of our own shiny new code, we had actually been incubating that code for a long time -- in many if not most cases, years. It might or might not look self-evidently different from the code you wrote out and attached to the bug, but it's gone through a lot on its way to you.
 
Augh. Let me try putting this another way:

Guava is (and must be) really conservative about new features and new API. That's absolutely critical for any project that lives as low in the stack as Guava does. That's totally independent of who suggests the feature, or whose use case is being served, or which open-source project it is, or how involved the community is.

If I had to estimate a distribution of the people-hours that go into Guava, I'd say it's
~25% arguing over API design and new features; arguing about method names, variable names
~20% doing "grungy" coding -- rewriting documentation; dealing with GWT compatibility and all the pain and misery involved with that; redesigning our large and complex test suites...
~25% code reviews. I don't know how people got the idea that "we don't want their code because it's not good enough." If we want the feature you're trying to add, then just be prepared for a strenuous code review process with dozens of comments, no matter how good you are.
~20% coding up new features.
~10% answering questions from the community -- on StackOverflow, on guava-discuss, etc.

If you spend any time on the Guava mailing list, you will see lots of these things going on, with both external and internal contributors. (Except the grungy, painful stuff, which we mostly do internally.)
 
I believe your 20% coding up new features is way off the mark. Maybe 5%? You have no idea how shielded you were as an intern. :-)
 
Hrrrrrrm. I totally know that I was pretty shielded from grunge work (which I feel kinda bad about), but I still feel like 5% might be too low? Certainly this past summer, between CacheBuilder and my time as an intern, I got the impression that a fair amount of time was being spent on new features between all of us.
 
I don't think there's nearly as much of a Google-internal/external dichotomy as folks suggest, with the possible exception of most of the painful grunge work. We have a lot of wonderful Google-external people who regularly contribute to feature requests and discussions -- +Emily Soldal and +Etienne Neveu come to mind off the top of my head, as well as some folks I can't find to tag. +Colin Decker and I are currently external contributors, but we're both getting hired to work on Guava starting in the fall.

I'd certainly say that 90% of the coding done for Guava is grungy internal stuff that isn't adding any new external API. (Some of this is more grungy than other stuff.) This is perfectly normal. A project this low in the stack will necessarily be conservative on new features, and downright obsessive about documentation, tests, and carefully organized code.

At the same time, 90% of the external code contributions we get are for new external features...much of which gets sent to us without bothering to ask if anyone else in the community thinks adding this feature is a good idea. What usually happens next is that someone goes, "Hold on there. Is this a good idea?" Some discussion ensues, and usually, the feature ends up in the pile of "keep this in mind for if we find more use cases/higher demand/a better approach, but like Josh Bloch says, we're in doubt, so leave it out." And that's the "black hole" Kevin refers to where most submissions end up.

I don't think any of this would change if Guava weren't attached to Google.

...That said, I should probably stop kicking this dead horse conversation.
 
For me personally, working on Guava would be a dream come true.
 
=D Not going to lie: it's totally my dream come true. I've consciously loved this sort of library work since I was 13.
 
I've spent quite a bit of time reading the guava source and have learnt a great deal from it and my coding style has changed because of it. I did have a patch for EventBus lined up, adding the ticket system for registration and I was kicking around the idea of a DelayQueue backed event bus for events that will happen "sometime in the future".