3 ms·
Mobile developer speaking here. As far as I can tell, most of the grousing about Google not being "open source" revolves around two points - one, they don't ac
by grammaton 16y ago
Mobile developer speaking here. As far as I can tell, most of the grousing about Google not being "open source" revolves around two points - one, they don't accept outside contributions, and two, you can't just install on whatever hardware you'd like / carriers do crappy things.
As far as point two goes - blame the carriers, not Google. It's not even necessarily clear that the carriers are in the wrong to do things like this - part of open source is that you are free to modify as you see fit. Sprint exercising this very right is why they have their own interface now. If all of the carriers choose to pull this shady crap, put the blame where it belongs.
As for point one - who ever said they have to? First off I'm not sure I'd want patches from Joe Schmoe running on my cell phone, and not even Google has all of the resources they need to review every submission they'd get. Secondly, plenty of open source projects are notoriously stingy about who they hand out commit privileges to - and the quality of the software in these cases more than justifies this policy.
If you're free to read, download, modify, and re-distribute the source code as you see fit, it's open source. If a third party intervenes to make this pragmatically difficult, then that's a different issue. Google has certainly been more open than any number of other software companies - only Apple really comes close, as far as I can tell, and they still hold back huge chunks of their code. Google deserves the press they get for being open source, because at the end of the day, they are.
- cullenking 16y agoGoogle wouldn't just take patches from any Joe Schmoe, and it certainly wouldn't be a huge overhead to deal with them. It would be similar to how a project like Rails takes community patches: people wanting to contribute strike up conversation in a bug tracking program or IRC with some core developers. They say "hey I wrote this cool patch that fixes this ticket". The core team member takes 20 minutes to check out the patch, and he merges it in to his branch and then commits it to the core repo. After this community member does this a few times, the core member begins to trust and understand their coding style, and gives them commit access. Doesn't take a ton of resources, and it encourages an open and vibrant community. The benefits of doing this "up front work" in vetting a new committer is, well, you get a new committer knocking off tickets.