Live data from Hacker News

The story of Google Guava and patches

plus.google.com

11–20 of 50 posts

Re: The story of Google Guava and patches

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

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, Chromium etc.

Re: The story of Google Guava and patches

#12
post #11

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. 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: developed in secret, in a dark room, and then dumped on the open source community. When no one was excited about it they shrugged their shoulders, confused about what they had done wrong.

I have no interest in Java, and I really hope someone forks this project and treats it like a real open source project.

Re: The story of Google Guava and patches

#13
post #6

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

Re: The story of Google Guava and patches

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

Re: The story of Google Guava and patches

#17
I'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 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.

So the Google/internal technologies will eventually stagnate.

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 (cough GWT), politics, etc.). Dunno, that's my impression.

Re: The story of Google Guava and patches

#18
post #6

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

Sounds like Martijn doesn't actually know much about Linux kernel development.

Patches get rejected from the kernel all the time for many of the same reasons listed in the linked post. It takes a long time for most new kernel contributors to get anything substantive in, and major changes almost never go in without huge reviews, fights, competing proposals, etc..

The only difference between that and what this post talked about is that for the kernel, a lot of the sausage making goes on in public (though far from all of it).

Re: The story of Google Guava and patches

#20
post #18
post #6

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

Sounds like Martijn doesn't actually know much about Linux kernel development. Patches get rejected from the kernel all the time for many of the same reasons listed in the linked post. It takes a long time for most new kernel contributors to get anything substantive in, and major changes almost never go in without huge reviews, fights, competing proposals, etc.. The only difference between that and what this post tal…

I actually think Martijn does understand that many patches will still get rejected - but he would like to still see some community contributions getting in (as opposed to the current message of 'stop contributing').

I personally think that a project with source available under an OSI Licene but no effort to respond to or build a community is not really an open source project.

Post reply on HN