This sounds like they are reversing the likely cause-and-effect:
"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.
Yes, I had the same reaction. I don't think the 'more people participating' observation is so useful.
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.
It does appear to be the 90-9-1% rule of the Internet at play, but you might be on to something.
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.
Continuing to thought that high-impact 'teams' have a cluster of fans around one high performer. Perhaps that just serves to motivate that person - a lively interest in their project shown by a variety of people.
Its a cycle - at certain states in the bootup of the project, things work one way, like when a new project gets started it only gets growing because there are key individuals with lots of talent - but as the project grows, the cycle flow changes and it works because it attracts more people who may not necessarily be 'as talented' but nevertheless contribute in other ways, and this thus brings in new talent, and so on and around it goes. I would not cast such an absolute light on it as you seem to propose; these things are an active process, not manifest material.
Yes, and double the issue of cause-and-effect with a huge lack of controlling variables. How does the language of the repository and/or number of developers with experience in that language correlate with number of contributors or stars? How about size of the codebase?
I suspect both larger repos, and more popular language choices dominate the "high-impact" projects.
In the teams where one person does more than all others combined, why is that described as "a successful team" rather than "a successful person who succeeds despite a bunch of hangers-on"?
I think that's looking at it the wrong way - you have one person who's talented and/or hard-working; contributing to the majority of the project and the others are the supporters - they're function may be primarily to allow the core contributor to do what he does best and while they take care of the more mundane tasks, provide their knowledge / experience and so forth when needed.
A little bit of encouragement and support goes a long way.
IME it's usually the other way around about who's doing the mundane tasks. Occasional contributors are most motivated by getting in their one pet feature; it's the project leader who takes on the dull task of cultivating an environment where other people can bolt on that feature successfully.
I've experienced this too. It only makes me hesitate when I have something to contribute, knowing the fighting I'll have to do for something as simple as better documentation.
The summary at the top seems to indicate that a team will have high impact if one guy does all the work and have a "team" unimportant work. So not quite what I was hoping to see.
"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.