What is meritocracy in open-source?

This follows on from my previous post about numpy culture.

In that post, I alluded to the idea of using seniority to weight opinions.  That is person A gives opinion X, person B gives opinion Y. Person A is more senior than person B and opinion X is accepted.  I will call this "brass ring merit" [1]

The idea of brass ring merit in open source is to define seniority to be an index of how much the person has previously contributed to the project, and proceed as above.  If you disagree with someone who has contributed more, you should be silent.

I think this is a terrible mistake and here I will try to explain why.

Many healthy societies use meritocracy, but, in a healthy society "merit" is not primarily defined by past achievement, but by quality of the argument.

In this world "merit" refers - primarily - to the thing that person A is saying now, and the sum of the qualities of the arguments of A over a recent period.  I will call this "acute merit".

To some this kind of merit feels like it will lead to chaos.  How will you know who is right without an index of seniority?  Acute merit is hard work, because you have to read and understand the argument, no matter who sent the email. Brass ring merit is much simpler: keep the hierarchy in mind and check the author's email address.

That is not the only problem with acute meritocracy.  In the brass ring world, if you are touching brass, then you do not have to worry about what other people say.  In an acute world, you must justify your opinion to any and all.  That takes time and energy.  You might turn out to be wrong, and you might have to change what you say or what you do or both.

To prefer acute merit is to create what George Dafermos calls:

... the unmediated participation of all community members in the process of formulating problems and negotiating decisions ... 

This does not mean we give each opinion equal weight. It means we judge the merit of the argument, not the merit of the author.

Is it true that healthy societies judge by acute merit?

 

Exhibit A: the authority of Linus Torvalds over Linux is contingent

In fact, for [Linus'] decisions to be received as legitimate, they have to be consistent with the consensus of the opinions of participating developers as manifest on Linux mailing lists. It is not unusual for him to back down from a decision under the pressure of criticism from other developers. His position is based on the recognition of his fitness by the community of Linux developers and this type of authority is, therefore, constantly subject to withdrawal. His role is not that of a boss or a manager in the usual sense. In the final analysis, the direction of the project springs from the cumulative synthesis of modifications contributed by individual developers.  George Dafermos, interview on governance of open source

Exhibit B: early Microsoft cared more about argument than seniority

[An important person called] Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?) Joel Spolsky on his work on Excel

See also Joel Spolsky on reviewing his spec with Bill Gates.

Exhibit C: Hewlett-Packard managed by Bill and Dave

Although the partners were demanding taskmasters, they created an environment in which managers were free to speak their minds. Steve Gomo was a young midlevel manager when he was asked to present the capital budget to the board of directors in 1978, because the executive that normally did the job was not available. Terrified, Gomo slaved to create a 12-slide presentation, and remembers practicing in front of a mirror for hours. Finally, he was called into to the meeting. Gomo's presentation went well until he showed a slide filled with financial data. Suddenly Hewlett piped up. "What is this gross asset and accumulated depreciation stuff? We only show one thing: net assets"

There was total silence. Gomo swallowed hard, and said, "Actually that's wrong Bill, we don't just look at net assets."

"Yes we do," said Hewlett firmly. Then turning to CFO Ed van Bronkhorst, he said, "We never look at anything but net assets, right Ed?"

"No Bill, he's right," said von Bronkhorst.

Suddenly the whole room burst out laughing at the thought of this rookie showing up Hewlett - except for Gomo who just wanted to get the heck out of there. Fumbling with his papers, he moved towards the door, when suddenly Packard stood up, dominating the room with his huge physical presence. "Oh shit, this can't be good,", Gomo thought.

Gomo's fear quickly vanished. "I just want it recorded in the minutes of this meeting that this was the best presentation on the capital budget that this board has ever received," said Packard, shaking Gomo's hand. Backfire, by Peter Burrows, p 63

Exhibit D: Intel's management style

 

This is from the Wikipedia article about Intel CEO Andy Grove:

Intel Senior Vice President Ron Whittier notes that Grove preferred to keep open channels of communication between employees, and encouraged people to speak their minds: "People here aren't afraid to speak up and debate with Andy." They termed this style "constructive confrontation." According to Grove's successor at Intel, Craig Barrett, "It's give and take, and anyone in the company can yell at him. He's not above it." Grove insisted that people be demanding on one another, which fostered an atmosphere of "ruthless intelligence."

Exhibit E: vigorous debate is characteristic of successful companies

 

Quoting here from page 75 of "Good to Great" by Jim Collins, in a section entitled "Engage in dialog and debate, not coercion". Collins is describing the atmosphere at the US company Nucor, as it transformed itself from a company making nuclear energy products into a company making steel. Ken Iverson was the CEO at the time.

... Iverson dreamed of building a great company, but refused to begin with "the answer" about how to get there. Instead he played the role of a Socratic moderator in a series of raging debates. "We established an ongoing series of general manager meetings, and my role was more as a mediator," commented Iverson. "They were chaos. We would stay there for hours, ironing out the issues, until we came to something ... At times the meetings would get so violent that people almost went across the table at each other.... People yelled. They waved their arms around and pounded on tables. Faces would get red and veins bulged out".

Iverson's assistant tells of a scene repeated over the years, wherein colleagues would march into Iverson's office and yell and scream at each other, but then emerge with a conclusion. Argue and debate, then sell the nuclear business; argue and debate, then focus on steel joists; argue and debate, then begin to manufacture their own steel; argue and debate, then invest in their own mini-mill, and so forth. Nearly all the Nucor executives we spoke with described a climate of debate, wherein the company's strategy "evolved through many agonizing arguments and fights."

Don't shut down the discussion, you'll kill the project

Acute merit leads to long, difficult, tiring discussion. It annoys people and tires them and makes them angry. But it is the essential engine of productive work.

Numpy, culture

I came to see, in my time at IBM, that culture isn't just one aspect of the game - it is the game (Louis V Gerstner, "Who says elephants can't dance?" p182) 

I started a thread about governance on the numpy mailing list.  The thread didn't go very well.   It occurred to me that discussion on the numpy list has often been poor, and that this is due to the culture in numpy.

The problem as I see it is that numpy has a weak culture of participation.  There is a fairly explicit culture on the numpy list of listening to opinions not on the basis of the argument, but on the basis of the person's perceived or measured importance.  In fact, Scott Sinclair codified this in a semi-serious suggestion on the mailing list thread, where importance was to be measured by number of code commits.

I believe this is why discussions on the numpy mailing list are often unsatisfying and disorganized, with people talking past the point and offering opinions without addressing the issues.  This follows logically from the fact that opinions are assessed by the importance of the person delivering them.  Therefore, there is no need for the opinion to build on the argument that has been put forward, or advance from any point but the initial view of the author.   The discussion then becomes a series of impressions, and does nothing but point out that some people's impressions are different from others.  We listen to the impression of the person who is most important.

I have sometimes felt that this way of doing business is based on the idea that successful open-source communities are based on meritocracy.  I think this is a serious misunderstanding, and I try and justify that in my next post about meritocracy in open source.