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.
11–20 of 50 posts
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.
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…
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.
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."
You can't have it both ways.
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.
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."
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).
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 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.