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.
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.