1. I mean are willing to accept outside contributions of code if people submit them, and put them in the codebase if they are acceptable.
2. I have the stats, but given that the vast majority of open source projects (Google or otherwise) don't ever grow past a few people, I don't see why it would be relevant? I also don't see why it's relevant whether they work for Google or not. It's not like we require projects follow a different process for Googler committers vs non, so i don't see how it's any different from a project where the committers are all really good friends who work on an OSS project together. We also hire a lot of committers to our open source projects. I'm guessing you want to make a distinction between "corporate open source projects", and "non-corporate open source projects", but in reality, making such a distinction would be a mistake, because the typical differences are in policies and preferences, and they apply equally well to either. IE What matters is the policies the project applies to committers and contributors, not whether they all work for the same company.
3. Again, I have stats, but for the vast majority of open source projects, just because most are willing to accept them, doesn't mean anyone ever contributes. This has nothing to do with Google, of course. If you look at the hundreds of thousands of projects on say, sourceforge, you will find the number that have either at least one not-same-email-domain-as-owner committer or non-trivial LOC written by a not-same-email-domain-as-owner committer else is quite low.
4. This seems to be a governance and social issue, I don't track it formally, as it would be quite difficult to do so.
It would also be wrong for us to try to force a model on folks. We give folks info about what we thinks are best practices, and in fact, free copies of the producing OSS book (Karl used to work with us :P), how they run their projects is generally up to them. We are happy to give them advise when asked, and are happy to consult in general.
Thanks for your reply. I appreciate the engagement.
---
I think you set up a false dichotomy between corporate open source and non-corporate open source. A better division would be between single organization projects and multi-organization projects. For example, OpenJDK is very much a corporate project - but in addition to Oracle, IBM, Apple and RedHat all have people heavily involved in development. That means that if Oracle were for whatever reason to lose interest the project wouldn't necessarily die (leaving aside patent issues).
On the other hand look at GWT, see in particular your colleague cromwellian excellent comments upthread. Here was a technology that Google was at one time devoting a great deal of resources to and was moving quickly and in exciting directions. A lot of companies built businesses on top of the GWT library. Now, for what seem like very good and valid reasons, Google has scaled back its efforts on the project. That's fine, but there is no community ready to pick up the slack. The reasons there is no one to pick up the slack are not technical or legal, but as you describe it "governance and social issue[s]".
When there is no path to becoming a committer, you are walled off from discussions about the future of the project and your patches are accepted reluctantly at best - why spend the time to deeply familiarize yourself with a codebase?
Except by being hired away by Google, which isn't exactly going to make your company thrilled to sponsor your work on a project.
2. I have the stats, but given that the vast majority of open source projects (Google or otherwise) don't ever grow past a few people, I don't see why it would be relevant? I also don't see why it's relevant whether they work for Google or not. It's not like we require projects follow a different process for Googler committers vs non, so i don't see how it's any different from a project where the committers are all really good friends who work on an OSS project together. We also hire a lot of committers to our open source projects. I'm guessing you want to make a distinction between "corporate open source projects", and "non-corporate open source projects", but in reality, making such a distinction would be a mistake, because the typical differences are in policies and preferences, and they apply equally well to either. IE What matters is the policies the project applies to committers and contributors, not whether they all work for the same company.
3. Again, I have stats, but for the vast majority of open source projects, just because most are willing to accept them, doesn't mean anyone ever contributes. This has nothing to do with Google, of course. If you look at the hundreds of thousands of projects on say, sourceforge, you will find the number that have either at least one not-same-email-domain-as-owner committer or non-trivial LOC written by a not-same-email-domain-as-owner committer else is quite low.
4. This seems to be a governance and social issue, I don't track it formally, as it would be quite difficult to do so. It would also be wrong for us to try to force a model on folks. We give folks info about what we thinks are best practices, and in fact, free copies of the producing OSS book (Karl used to work with us :P), how they run their projects is generally up to them. We are happy to give them advise when asked, and are happy to consult in general.