You’ve probably done it. I’ve done it. We all do it.
You see a brilliant piece of code, a game-changing open source library, or a framework that reshapes an industry. And then you look at the creator. You read their tweets. You watch their interviews. And suddenly, you’re not just evaluating their code anymore—you’re evaluating their soul.
We have a collective addiction to the halo effect of technical success. We assume that because someone can build a distributed system that scales to millions, they must also have profound insights on politics, economics, or human nature. This is a cognitive trap. Technical brilliance is not a moral compass.
Take Matz—Yukihiro Matsumoto, the creator of Ruby. The community has spent years debating whether he’s “nice” enough. Whether his personal views align with the progressive values of the tech scene. Whether he deserves to be the face of the language. But here’s the uncomfortable truth: It doesn’t matter whether Matz is nice. What matters is whether his code works. The Ruby language is a masterpiece of developer happiness. That’s the contribution. Everything else is noise.
But we can’t stop ourselves. We extend the same logic to Elon Musk—brilliant at engineering and business, suddenly an oracle on geopolitics and AI safety. To Jordan Peterson—clinically sharp on psychology, yet treated as a philosopher of everything. To DHH—creator of Ruby on Rails, now a lightning rod for every debate on remote work, productivity, and corporate culture. Smart people get a pass to be wrong about everything else.
And then there’s the flip side. The open source community is eating itself alive over ideological purity tests. We demand that contributors not only write good code, but also pass a political litmus test. We cancel maintainers for a tweet from 2015. We demand they sign pledges, denounce things, perform virtue. Filtering code through a political lens creates an intellectual monoculture that kills innovation. The moment you judge a pull request by the author’s politics, you’ve lost the plot.
So what’s the right path? It’s the uncomfortable middle. Judge code on its technical merit. Judge the creator’s ideas on their own merit. But stop conflating the two. You can use Rails and disagree with DHH on half the things he says. You can love Ruby and think Matz is a jerk (he’s not, but you could). The technology stands independent of the creator’s persona.
This doesn’t mean we should ignore harmful behavior. It means we need to be precise. A maintainer who is abusive in issue trackers is a problem for the community, not because their views are wrong, but because they create toxicity. That’s a conduct issue, not an ideology issue. We don’t need nice developers. We need good code and respectful communities.
The next time you find yourself admiring a creator’s every word because they built something brilliant, stop. Ask yourself: Is this technical genius, or is this the halo effect talking? And when you’re tempted to reject a library because the author’s politics offend you, ask yourself: Is this about the code, or about my comfort?
Because the open source world is built on the principle of meritocracy—but only if we can separate the work from the worker. If we can’t, we end up with a world where only the ideologically pure are allowed to innovate. And that world is poorer, slower, and less creative. Let the code speak for itself. The creator’s opinions are just noise.
FAQ
Q: What if a creator's behavior is genuinely harmful, like harassment or abuse?
A: That's a conduct issue, not a political purity test. Harmful behavior should be addressed through community guidelines and governance, not by rejecting their code. The code remains independent; the community can and should enforce standards of behavior.
Q: Doesn't funding a creator through donations or sponsorships imply endorsing their views?
A: It can feel that way, but it's a separate decision. You can choose to support the code without supporting the person's ideology. Many projects have neutral foundations. The key is to decouple the financial support from the personal endorsement.
Q: Isn't the idea of judging code purely on merit a naive fantasy? We all have biases.
A: It's not about perfection—it's about intent. The goal is to minimize the interference of personal biases in code review and project governance. Recognize that biases exist, but strive to evaluate technical contributions objectively. That's the best we can do.