Shame how such a cool project as node.js can drown in political fingerpointing. The only measurement that counts (in my opinion) is cold hard code contributions.
It's a little extreme to say that cold hard code is the only thing that counts. Years ago I worked with someone who contributed more cold hard code than anyone else I've known. A brilliant developer, probably one of those "10X" people they talk about: that rare combination of outstanding technical chops and "get the job done" productivity.
But more than once, he jumped into projects and features that he knew other people on the team were already working on, implemented them himself in a rush without coordinating with the other developers, and pushed his code instead.
Sometimes he would take shortcuts to get it done faster while his teammates were working on a more fully developed version of the feature. And since he was first, that was the code that would be used. The other developers were left with nothing to show for their efforts, less of a feeling that they were valued members of the team, and a significant loss of reputation in the eyes of management.
Cold hard code is important, of course. But it's not the only thing.
Who was running that team? Blame should be on leadership for running an inefficient team where team members don't share and coordinate so that common projects, code, libs etc can be flushed out.
I fully agree that it sounds awful for a project to go down due to politics. But only paying attention to code reviews ignores how the community feels, as well as non-code work. For example, look at Rod Vagg's contributions to node: https://github.com/nodejs/node/commits?author=rvagg
At least from the first page, it seems he's mostly working on documentation, specifically changelogs. But honestly, those changelogs are fantastic and definitely make a difference in my life (I don't want to comb through tons of commits to figure out what has changed between versions of Node). It might not be code per se, but the contribution is noticeable.
Even if all you do is make people feel welcome in a community or bring people in, those are still worthwhile (new people can mean more code). And if you're an amazing programmer but make everyone want to leave the project, one can see how that would also affect the code (contributors leaving).
Usually, one who writes change logs is part of leadership deciding what should be worked on next, strategy, prioritizing and often times accountability as well. This is because they have a birds eye view of everything that is being worked on. Not easy and often thankless.
People who choose to contribute under their real names or easily cross-referencible pseudonyms are taking a calculated risk. People who participate in political structures like the TSC -- which despite its name is a political, not a technical effort -- incur risks that are intrinsic to being in a high-profile leadership role.
"Cold hard code" contributions are an option available to anyone who feels comfortable with donating their labor under an opaque pseudonym. It's a good way to proactively shield oneself from disputes of this nature. It's a natural continuation of the quip "On the Internet, nobody knows you're a dog" -- except if you tell everyone you're a dog. Plenty of people contribute to collaborative projects solely on the merit of their contributions, even as many projects have come to follow the trend of considering other factors as well [1].
If you ever want to leverage your open source activities in the real world, you have no choice. How can you put it on your CV if your name's not on it? Or write a book or give talks at conferences or write a blog etc.
Are you going to accept cold hard code contributions from someone who regularly writes excellent code and engages in political fingerpointing?
Are you going to accept cold hard code contributions from someone who regularly writes excellent code and has the technical sense of the community about 80% of the time, and is at odds with the technical sense of the community 20% of the time, and regularly tells everyone involved in the 20% case that they're idiots and the project will fail if they don't merge the remaining 20% of their code (which is technically excellent too, just not implementing the design people want)?
Are you going to accept cold hard code contributions from someone who generally writes good code that works on the first try but refuses to listen to code reviews?
Are you going to accept cold hard code contributions under the wrong license? (Licenses are politics, not code!)
That sounds nice until you think about it -- what code are you writing? Who decided on the the feature you're writing? Who's writing the docs, and tutorials, and putting together conferences and paying bills and maintaining tax status and filing paperwork, and...?
Lots of real people aren't robots, and are concerned with other feature software the environment in which they choose to spend time to make a product than just the resulting output. And those people are going to choose environments based on the features of concern.
But more than once, he jumped into projects and features that he knew other people on the team were already working on, implemented them himself in a rush without coordinating with the other developers, and pushed his code instead.
Sometimes he would take shortcuts to get it done faster while his teammates were working on a more fully developed version of the feature. And since he was first, that was the code that would be used. The other developers were left with nothing to show for their efforts, less of a feeling that they were valued members of the team, and a significant loss of reputation in the eyes of management.
Cold hard code is important, of course. But it's not the only thing.