You’ve seen the leaderboard. Adam is the #1 contributor to OpenCode by line count. Thousands of lines. First on the chart. But here’s the uncomfortable truth nobody wants to admit: Adam might be the biggest liability in the project.
Let me say it louder: Measures like line count don’t reward impact. They reward bloat.
I’ve been in enough code reviews to know that the person who writes the most lines isn’t the hero—they’re often the one creating technical debt that the rest of the team will clean up for years. The real heroes are the ones who delete 500 lines and replace them with 10. The ones whose commits are small, focused, and elegant. But those commits don’t climb the leaderboard.
“But Adam is just writing a lot of code, that’s a good thing, right?” Wrong. Line count is the vanity metric of open source. It tells you who types fast, not who builds well.
Think about it: You’re a maintainer. You see a pull request that adds 2,000 lines. It looks impressive. It gets approved. Six months later, you’re debugging a cascade of bugs that trace back to that PR. Meanwhile, another contributor submitted a 50-line fix that prevented an entire class of errors—but nobody gave them a badge for it.
I talked to a friend who works on a major open source project. He told me: \”We had a top contributor by lines. When we finally audited the code, 40% of it was legacy that nobody ever used. We cut it, and the project ran faster with fewer bugs.\” The metric we celebrate is the metric that sabotages us.
So what do we do? Stop glorifying line count. Start celebrating deletion. Start rating commits by clarity and impact, not size. If your name is at the top of the line count leaderboard, ask yourself: Am I making the project better, or just making it bigger?
The next time you see OpenCode’s leaderboard, don’t applaud Adam. Ask: Where is the contributor who deleted the most lines? Where is the contributor who closed the most issues with a single commit? Those are the real top contributors—and they’re invisible because we chose the wrong metric to worship.
FAQ
Q: Isn't writing more lines a sign of hard work?
A: Hard work doesn't equal smart work. More lines often mean more complexity, more bugs, and more maintenance. The goal is to solve problems with minimal code, not maximal lines.
Q: How should we measure contributions instead?
A: Measure impact on users, bug fixes, code reviews, and documentation improvements. Consider deletions as valuable as additions. Use metrics like issue resolution rate or code maintainability scores.
Q: Aren't all lines of code valuable in open source?
A: No. Dead code, duplicated logic, and overly verbose solutions waste the whole community's time. The best contributions are those that reduce the overall cognitive load of the codebase.