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.

I'm not sure where you came up with any of these assertions, as they are all simply false.

First, plenty of Google projects allow outside contributions. There are over 1400 open source Google projects (The number is actually much larger, but i've only counted those that wanted to be identified specifically as Google projects), and >98% of them allow contributions the last time I looked. In fact, it's easier to simply list the ones that don't than the ones that do. I have to imagine you have your own list of what you think are "Google projects", and are working off of that when you made your assertion.

Second, there is definitely no "attitude pervasive at Google that open source is a great marketing tool, but that it's a one-way street". As the guy generally responsible for helping teams that want to open source stuff, I can tell you that in 6 years, I've run into this attitude maybe 5 times out of the (again) 1400+ projects that got released. That's not to say everyone open sources stuff at Google for the same reason, but there is certainly no pervasive attitude like you describe. The reality is a lot of folks at Google have released open source projects for a lot of reasons, and of those reasons, "marketing tool" is pretty far down the list.

BTW, none of this is to say I agree with Kevin's approach to running Guava; I don't, for various reasons. But in the end, he (and the rest of the guava folks) are the ones doing the work, and the issues here will work themselves out in the normal way (either people will grudgingly accept it and keep using guava, or some fork will become more popular eventually and take over). In either case, Kevin making a clear statement on the situation helps move things along one way or the other, and is a lot more than you can get out of other OSS projects that do something similar.

What do you mean exactly by "allow outside contributions"?

Do you have stats on the number of projects with at least one commiter that doesn't work for google? The number of projects with non-trival LoC written by non-employees? The number of projects with an external mailing list as the place where project decisions are hashed out?

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.