[notacoward]

OP mentions three things: staging their work, velocity, and sense of agency/ownership. All three are problematic. Often those who have worked with a component the longest and/or wrote significant parts of it become its maintainers, either formally or de facto. As a maintainer (I've been one myself) it's simply easier to get commits in, not necessarily because you're better at the work but because of the role itself. You never have to re-work your commits to conform to someone else's idea of how things should work. People trust you, so reviews are often cursory. Many maintainers return that courtesy by subjecting others' work to excruciating review, slowing them down. Sometimes it's intentional, sometimes not, but the result's the same. Also, a maintainer often has many commits that started off as someone else's idea but that person didn't have the time or knowledge to complete them, so those are kind of low-hanging fruit that inflate the numbers. A mediocre maintainer will usually still have more commits than even the most talented non-maintainer. Calling them "top performers" because of something that's part of the role seems a bit circular.

So much for velocity and ownership. As for the part about staging commits, I'd like to see some evidence. In my experience there's no difference, or sometimes the maintainers are even less likely to break up commits. This can be because maintainers are often charged with making commits with lots of internal dependencies that make them harder to break up, or because it's easy to get a stamp even on a questionable commit from people who are dependent on their goodwill to get their own commits in.

[temac]

OTOH I'm tired of people who don't "have the time or knowledge to complete [their ideas]".

Ideas are cheap. Show me the code.

Asking, explicitly or implicitly, for others to "implement/finish" their ideas is easy. I would even call never finishing / polishing anything very disrespectful: I'm not (should not be) here to cleanup after "talented" individuals. This is detrimental to my own "ideas."

So at least, if not anything else, I better be recognized for the boring and tedious maintainership work I do and that talented people with their "ideas" refuse to perform...

[notacoward]

> Ideas are cheap. Show me the code.

I mostly agree with you, but also don't want to be too developer-centric. Sometimes the ideas come from people who aren't primarily developers - production engineers, system architects, etc. Let's say an idea from such a person is fundamentally good and will benefit the project but they lack the time or skill to do more than prototype it. What should happen?

(a) Drop it on the floor.

(b) Let their patch(es) languish and eventually get reaped. Same result in terms of functionality, plus contributes to an "maintainers aren't open to new ideas" reputation which harms recruitment/retention.

(c) Get a developer with more knowledge/skill to finish it. In general, this is just going to be the maintainer, because nobody else will have a strong enough sense of ownership to sacrifice time toward their own goals for it.

Obviously this is going to be case by case, but I'd say that (c) is at least sometimes a valid answer. Depending on the makeup of people involved with the project, which in turn might depend on the nature of the project itself, it might even be quite often.

[temac]

I kind of agree with you.

I was thinking of people perfectly able to do/finish the job. If that's not their job to begin with, they have another one, and can be evaluated on it. If it's just that their time is too precious to do it (and it can even be!) and they will actually bring value in another way, then so be it, but let's not overestimate the value on dev on that project compared to people actually doing the work. Because we are not talking about design vs production, we are usually talking about rough-high-level-design vs high level refinement/debugging + all-level-design + QA + iterating, rince and repeat...

And like I said: ideas are cheap. Fundamentally. Well, most ideas, but this would need a case by case judgment to recognize remarkable ones out of the mass, so I'll continue with my simplification that "ideas are cheap." If I say that a micro kernel still makes a lot of sense and should be the future of new OS / VMs / etc, well it is controversial, and maybe Linus won't agree, but maybe if just enough people put some efforts to develop an excellent and very successful system from that, maybe Hurd done right, while I simply get to my next idea, maybe if the system is eventually successful I should not be overly praised for that. Maybe the people who did the work should. The mere idea bringers will be judged on other aspects anyway, and it does not retire anything from all their contribution everywhere, maybe other activities, etc... I'm not trying to declare the superiority of development vs other things. I'm trying to explain that development is to be judged by development criteria.

And so in the end, counting the number of commits (or whatever), yes it is kind of an idiotic metric but maybe not as much as some people seem to think. I see it more like the estimation of complexity via the number of LOC approach: it's rough, you may need to apply various adjustments here and there if you look more closely, it may be biased by various non optimal feedback loops, it may lead to a few false positives and negatives, but it is still an interesting metric to begin to understand what is happening in a project.

[notacoward]

Well said. I guess it's a good example of how metrics can be useful but not definitive.

[modernlearner]

It does sound from the article as if incumbents will always have a huge advantage and will be more likely to be labeled top performers.