"Even in larger teams, high-impact teams have core and support cadres. A small number — sometimes just one — of the team do the majority of the work, while other, non-core members act in support roles."
Successful projects will tend to bring in a larger number of contributors, most of whom will only make a few contributions. So successful projects will tend to have this pattern. But it is the success of the project that creates that pattern, not the other way around. Lots of projects are not successful, so no one ever contributes to them.
But I find the related -- and almost opposing -- one to be useful and thought-provoking, and matching my experience and suspicions:
> Even in larger teams, high-impact teams have core and support cadres. A small number — sometimes just one — of the team do the majority of the work, while other, non-core members act in support roles...
> High-impact teams are more likely to be ‘dominated': where the lead member contributed more work than all the other contributors combined.
I think sometimes we think to have success, we have to widely distribute the responsibility/authority. This apparently shows that that's not neccesarily the case, a succesful project can still have a very small number of people (often just one) doing the bulk of the work and with authority (formal or informal) for the direction of the project.
I'm not sure that means you should try to create this as a means of success. On the other hand, it can be hard, but possible, to have a clear direction and goals and stay consistent to them, with "too many cooks".
That successful/influential projects have lots of people participating is not surprising -- success draws contributors. What may be counter-intuitive is that even after this happens nonetheless there are still usually only a few (or often one) person providing the heavy lifting.
In a more traditional organization you would have architects and other senior development leads plowing the way with a number of subordinates that provide the necessary but dirty grunt work scaffolding around the central architecture. It's not that they're doing more work. Instead they are charging through the hard problems that more junior developers struggle around, but don't have the time to dive deep into tiny implementation details required for large projects.
The interesting data would likely come from these closed sourced projects and complement the data of the open projects. I would love to see that analysis and comparison.
I suspect both larger repos, and more popular language choices dominate the "high-impact" projects.
A little bit of encouragement and support goes a long way.
I have found critical bugs in some projects and the people with repo access let the pull request sit there for a year or more.
