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.

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

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

[1] https://news.ycombinator.com/item?id=14539465

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.

"Cut the crap, Kent; you've built a weapon!"

Unless you're the only contributor, you're still going to have to deal with other people, and the interactions with other people on the project.