I used to an be external contributor to open-source GWT, and then became a Google employee to work on the GWT team and the situation really has nothing to do with elitism or culture.
It basically boils down to a matter of resources. When I started as an open source contributor to GWT, it was used by external developers, but not really used internally by Google, so changes made by external committers couldn't possibly break anything.
Slowly over time, more and more Google properties started using GWT, and suddenly, you had the situation where an external user could submit a patch, that passed all the GWT unit tests, but broke major Google properties (e.g. AdWords, Google Groups, Wallet/Checkout, etc) Google builds everything from head, so when you do an internal commit, not only do your unit tests run, but the unit tests from every project that depends on GWT, so you find very quickly if your patch broke real applications. This happens all the time. I commit, pre-submit queue for GWT is green (all tests past), then hundreds of other projects get their chance, and there's always 1 or 2 that break, not always because of GWT per se, sometimes because of bad code in those projects.
The problem is, there is no way for external committers to get notified of internal (potentially confidential) apps breaking on their changes. This meant that every external commit would need to be reviewed and proxied by someone on the GWT team.
Now, back when we had over 20+ people working on GWT, it wasn't hard. Now there are only 5 full time committers, and it has become a lot more difficult to keep up with the external community and support internal users.
I have been internally advocating that we "re-open source GWT". That is, we make the "source of truth" be an external repository, possibly re-hosting it on GitHub or Google Code, and fork it off from the internal version. We grant all our of best and dedicated contributors rights to administer and commit on equal footing with Google employees, and we run external continuous build systems for it.
On the innovation front, I think it's true for gwt-user, but for the compiler, I've hardly gotten any external contributions for optimizations and almost all of the improvements in speed and code size have arisen internally. This may indicate that we should run separate open source projects for the compiler/tools and the libraries, splitting them up and separately managing them.
But the GWT team IMHO was never elitist, just saddened that contributions were piling up and we lacked the bandwidth to review and commit them in a timely manner. I feel bad about it, given the time people put in, and I've been spending time recently trying to collect all outstanding patches for landing into GWT 2.5.
Hi Ray. You make good points, more than I can justly respond to right now.
Briefly, I did not know GWT was initially not used widely within Google--I had assumed it was from near-day-1.
The re-open sourcing sounds cool, although it would be interesting to see how it could play nicely with the internal build-from-head system you guys have. E.g. to avoid effectively forked projects.
Speaking of building from head, I'm sure it's a net win, but, as an outsider, the handcuffs of backwards compatibility seem overly tight. More frequent major-point releases that could clean up cruft might be nice. Not sure how you guys handle major-point releases internally? If at all?
And, yeah, elitist was too strong, especially to apply to individual developers. However, not just recently, but over the lifespan of GWT, it hasn't spawned an external dev community (AFAIK), so it seems like something is off.
The history of GWT was that it was started by Joel and Bruce and acquired by Google. Internally, at the time, Google had been using Closure Compiler and millions of lines of Javascript code, so just from inertia, there would not have been much use in the beginning, because it's not like the GMail team is going to rewrite GMail in GWT over night. Really, the first high profile consumer facing project done with GWT was Wave. AdWords is also GWT, but not very sexy.
I come from a background of using Maven to build my projects, and Google's internal build system is somewhat maven like, but it doesn't let you specify versions in dependencies, so you always end up depending on HEAD. To me, this is the root problem making it hard for projects that live simultaneously in the open and closed worlds.
It would be interesting to see how the Guice team handles it, but maybe they're patch velocity is small.
As for why GWT didn't get a huge external community of committers? I do think it has something to do with the fact that it is a gated community, that people feel like they don't "own" it, Google does. Maybe re-open sourcing it and rebranding it as "Open Web Toolkit" or "Community Web Toolkit" would somewhat remove those mental blocks.
I would love for the open community to be true owners of GWT, and Google as just a contributor. I've been lobbying to make it happen, and I hope it does. Too many external people have put in a lot of work, they deserve it.
Why was GWT team reduced? Developers were moved to Dart project?
Is there any schedule for 2.5? We are waiting for SourceMaps, since debug mode is working slow in Chrome & IE, and with Firefox there always is a version gap. Safari plugin is also broken since version 5.
I can't fully explain why it was reduced, but it's several factors:
1) Some people left, for various reasons (like being at Google for 6+ years), for example, 5 left to go to different startups.
2) Some went to work on Dart
3) Some when to work on Chrome
4) Some went to work on a secret project
5) Maturity. At Google, 20 is considered a "big" team. The Closure Compiler, on which GMail, Docs, Google +, Google Search, Google Maps, etc is based is not even staffed, it's just the result of 20% contributions. GWT was, from an organizational standpoint, even in the wrong division. It should have been in infrastructure/dev-tools/etc, but instead it was under a management chain that cared about other stuff.
GWT 2.5 will be released very soon. I am trying to collect all external contributions that have been languishing and land them first.
If only I was a senior VP. :) There are many many Googlers who would like projects to be more open source than they are, since the company has aggressively hired people who value open culture. It's not always possible, I don't know the Android team's constraints, but I would gather if you're working with an OEM on a new secret device, they don't want hints of it leaking in the public repository. :(
I'm with stephen on that. You say each of you working in the GWT team, as a person, didn't have enough time to do review of submissions. To you there was not enough bandwidth.
I say your employer didn't allocate enough bandwidth. It prioritized internal needs so far over the free software approach that the free software aspect died off completely.
You are right in saying none of the developers was an elitist; you are not right in saying that Google in itself wasn't elitist. Your manager's manager's manager knew exactly what he was doing when he allocated this many people to your team, and not more; when he didn't allocate people to do full-time community submission review when there was obviously enough work for multiple such positions.
That's one issue with "sponsored but free" projects: they never are really free because the work gets prioritized that benefits the sponsor, not the work that benefits the project as a whole. Projects are forcibly steered to keep their center of gravity and biggest source of submission inhouse, under the control of the sponsor. It's a very simple strategy of making a "free" project non-free; you can immediately pull the plug on a project which misbehaves: first you make sure the developers not under your control get stalled and discouraged, and that their work becomes harder; they cannot keep up. They couldn't continue the work being done on their own. Then, you make sure the others are so engrossed in work you, the sponsor, assign to them that they cannot keep a project healthy through intellectual exchange with externals. You build a glass wall around the project. You make internal documentation that does not need to be redistributed with your "free software" because it is not a part of it according to the law. The (complicated) build system isn't, either. Finally you have complete control of the direction, progress, and life of the project. You, the sponsor, can submit the project to your neurotic desires, which we, developers, all know. The typical corporate bullshit-o-rama that never fails to make a good project go to hell.
Open source is not a salvation.
The only way to prevent really good projects which have received huge amounts of contribution from skilled developers from becoming useless wastes of talent is to make sure that external requests, contributions, and requirements are taken at face value and are given a chance to be evaluated with the same attention as internal problems. This cannot happen in a corporation where the management performance is counted as a function of successfully resolved projects coming from internal clients. This cannot happen at all if there are internal clients, because "internal client" is a term made exactly with the point of being able to work better with "internal" clients than "external" clients. Sponsored software is not free software unless it is something akin to a donation, where the sponsor is not given creative or otherwise rule over the project.
It basically boils down to a matter of resources. When I started as an open source contributor to GWT, it was used by external developers, but not really used internally by Google, so changes made by external committers couldn't possibly break anything.
Slowly over time, more and more Google properties started using GWT, and suddenly, you had the situation where an external user could submit a patch, that passed all the GWT unit tests, but broke major Google properties (e.g. AdWords, Google Groups, Wallet/Checkout, etc) Google builds everything from head, so when you do an internal commit, not only do your unit tests run, but the unit tests from every project that depends on GWT, so you find very quickly if your patch broke real applications. This happens all the time. I commit, pre-submit queue for GWT is green (all tests past), then hundreds of other projects get their chance, and there's always 1 or 2 that break, not always because of GWT per se, sometimes because of bad code in those projects.
The problem is, there is no way for external committers to get notified of internal (potentially confidential) apps breaking on their changes. This meant that every external commit would need to be reviewed and proxied by someone on the GWT team.
Now, back when we had over 20+ people working on GWT, it wasn't hard. Now there are only 5 full time committers, and it has become a lot more difficult to keep up with the external community and support internal users.
I have been internally advocating that we "re-open source GWT". That is, we make the "source of truth" be an external repository, possibly re-hosting it on GitHub or Google Code, and fork it off from the internal version. We grant all our of best and dedicated contributors rights to administer and commit on equal footing with Google employees, and we run external continuous build systems for it.
On the innovation front, I think it's true for gwt-user, but for the compiler, I've hardly gotten any external contributions for optimizations and almost all of the improvements in speed and code size have arisen internally. This may indicate that we should run separate open source projects for the compiler/tools and the libraries, splitting them up and separately managing them.
But the GWT team IMHO was never elitist, just saddened that contributions were piling up and we lacked the bandwidth to review and commit them in a timely manner. I feel bad about it, given the time people put in, and I've been spending time recently trying to collect all outstanding patches for landing into GWT 2.5.