
What makes teams successful? 150,000 GitHub projects analyzed - greg
http://research.gigaom.com/2014/07/part-1-what-makes-teams-successful/
======
lkrubner
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.

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

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

------
jodrellblank
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"?

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

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

------
codexon
I find that most mature projects are incredibly hesitant to accept patches.

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.

~~~
getsat
Any examples/PR links?

~~~
codexon
Sorry but I'm not willing to make a public enemy out of any of these projects
just to prove a point.

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

