3 ms·
The issue is that calling a system meritocratic doesn't give a functional definition of merit, and people tend to evaluate merit in very biased ways; see e.g. t
by 0xcde4c3db 8y ago
The issue is that calling a system meritocratic doesn't give a functional definition of merit, and people tend to evaluate merit in very biased ways; see e.g. the halo/horn effect [1]. Possibly the simplest and most pervasive bias, though, is that work by familiar people is viewed as more valuable than work by unfamiliar people (cf. nepotism, cronyism, NIH).
[1] https://en.wikipedia.org/wiki/Halo_effect https://en.wikipedia.org/wiki/Halo_effect
- dvfjsdhgfv 8y agoOK but this is a completely different discussion: defining what meritocracy means vs. rejecting it altogether. The dynamics of open source projects is a very interesting issue, but in general in most healthy environments it works like this: someone sends a patch, and it looks really good. They send another one, and another, and everyone can see that these patches are actually useful (not fixing typos in the comments...). With time, whether in formalized or informal way, that person has more and more to say as others respect their opinion. Why? Because they demonstrated they know the project, they devote their time to it, they can make reasonable decisions. So they are trusted more than a random guy who just joined yesterday, even though the same person - with time - can prove themselves and reach the same or better position in the project. This is called "meritocracy" and it's the base of most FOSS projects. Of course it's not ideal and there are abusers - overly protective maintainers who refuse patches from anyone, or small groups of friends who dislike newcomers - but in general it works very well and I see no reason to destroy it.