Perhaps the most important lesson is the one that's mentioned several times in the thread already. Some tasks scale better to larger groups of people than others.
As programmers, this should be somewhat intuitive. Certain tasks scale better to multiple threads or multiple processes than others. Loosely coupled problems are easier to do in parallel. Problems that are tightly coupled due to interdependency often require so much communication and coordination overhead as to be infeasible or inadvisable in broadly scaled implementations.
Everything that is difficult about interdependency, communication, and coordination among some otherwise simple subroutines is compounded when you replace those bits with people. Coordination and communication between people is not so simple and constrained, and therefore the costs rise even faster.
If you really want to be part of the core Perl 6 team, then all you have to do is earn your keep among them. This is much like what Eric S. Raymond calls "Meritocracy" -- everybody is given an equal chance democratically, but their contribution toward the goal is what gives them their final influence. Your share of the action is what you make of it.
In fact, I'd say that if things were not this way, nothing would get done at all. Why hold back the progress being made by those willing and able to do the work waiting for input from people not willing and able to provide it? | 