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