Digifesto

May 24, 2018

thinking about meritocracy in open source communities

There has been a trend in open source development culture over the past ten years or so. It is the rejection of ‘meritocracy’. Just now, I saw this Post-Meritocracy Manifesto, originally created by Coraline Ada Ehmke. It is exactly what it sounds like: an explicit rejection of meritocracy, specifically in open source development. It captures a recent progressive wing of software development culture. It is attracting signatories.

I believe this is a “trend” because I’ve noticed a more subtle expression of similar ideas a few months ago. This came up when we were coming up with a Code of Conduct for BigBang. We wound up picking the Contributor Covenant Code of Conduct, though there’s still some open questions about how to integrate it with our Governance policy.

This Contributor Covenant is widely adopted and the language of it seems good to me. I was surprised though when I found the rationale for it specifically mentioned meritocracy as a problem the code of conduct was trying to avoid:

Marginalized people also suffer some of the unintended consequences of dogmatic insistence on meritocratic principles of governance. Studies have shown that organizational cultures that value meritocracy often result in greater inequality. People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions. Meritocracy also naively assumes a level playing field, in which everyone has access to the same resources, free time, and common life experiences to draw upon. These factors and more make contributing to open source a daunting prospect for many people, especially women and other underrepresented people.

If it looks familiar, it may be because it was written by the same author, Coraline Ada Ehmke.

I have to admit that though I’m quite glad that we have a Code of Conduct now in BigBang, I’m uncomfortable with the ideological presumptions of its rationale and the rejection of ‘meritocracy’. There is a lot packed into this paragraph that is open to productive disagreement and which is not necessary for a commitment to the general point that harassment is bad for an open source community.

Perhaps this would be easier for me to ignore if this political framing did not mirror so many other political tensions today, and if open source governance were not something I’ve been so invested in understanding. I’ve taught a course on open source management, and BigBang spun out of that effort as an experiment in scientific analysis of open source communities. I am, I believe, deep in on this topic.

So what’s the problem? The problem is that I think there’s something painfully misaligned about criticism of meritocracy in culture at large and open source development, which is a very particular kind of organizational form. There is also perhaps a misalignment between the progressive politics of inclusion expressed in these manifestos and what many open source communities are really trying to accomplish. Surely there must be some kind of merit that is not in scare quotes, or else there would not be any good open source software to use a raise a fuss about.

Though it does not directly address the issue, I’m reminded of an old email discussion on the Numpy mailing list that I found when I was trying to do ethnographic work on the Scientific Python community. It was a response by John Hunter, the creator of Matplotlib, in response to concerns raised when Travis Oliphant, the leader of NumPy, started Continuum Analytics and there were concerns about corporate control over NumPy. Hunter quite thoughtfully, in my opinion, debunked the idea that open source governance should be a ‘democracy’, like many people assume institutions ought to be by default. After a long discussion about how Travis had great merit as a leader, he argued:

Democracy is something that many of us have grown up by default to consider as the right solution to many, if not most or, problems of governance. I believe it is a solution to a specific problem of governance. I do not believe democracy is a panacea or an ideal solution for most problems: rather it is the right solution for which the consequences of failure are too high. In a state (by which I mean a government with a power to subject its people to its will by force of arms) where the consequences of failure to submit include the death, dismemberment, or imprisonment of dissenters, democracy is a safeguard against the excesses of the powerful. Generally, there is no reason to believe that the simple majority of people polled is the “best” or “right” answer, but there is also no reason to believe that those who hold power will rule beneficiently. The democratic ability of the people to check to the rule of the few and powerful is essential to insure the survival of the minority.

In open source software development, we face none of these problems. Our power to fork is precisely the power the minority in a tyranical democracy lacks: noone will kill us for going off the reservation. We are free to use the product or not, to modify it or not, to enhance it or not.

The power to fork is not abstract: it is essential. matplotlib, and chaco, both rely *heavily* on agg, the Antigrain C++ rendering library. At some point many years ago, Maxim, the author of Agg, decided to change the license of Agg (circa version 2.5) to GPL rather than BSD. Obviously, this was a non-starter for projects like mpl, scipy and chaco which assumed BSD licensing terms. Unfortunately, Maxim had a new employer which appeared to us to be dictating the terms and our best arguments fell on deaf ears. No matter: mpl and Enthought chaco have continued to ship agg 2.4, pre-GPL, and I think that less than 1% of our users have even noticed. Yes, we forked the project, and yes, noone has noticed. To me this is the ultimate reason why governance of open source, free projects does not need to be democratic. As painful as a fork may be, it is the ultimate antidote to a leader who may not have your interests in mind. It is an antidote that we citizens in a state government may not have.

It is true that numpy exists in a privileged position in a way that matplotlib or scipy does not. Numpy is the core. Yes, Continuum is different than STScI because Travis is both the lead of Numpy and the lead of the company sponsoring numpy. These are important differences. In the worst cases, we might imagine that these differences will negatively impact numpy and associated tools. But these worst case scenarios that we imagine will most likely simply distract us from what is going on: Travis, one of the most prolific and valuable contributers to the scientific python community, has decided to refocus his efforts to do more. And that is a very happy moment for all of us.

This is a nice articulation of how forking, not voting, is the most powerful governance mechanism in open source development, and how it changes what our default assumptions about leadership ought to be. A critical but I think unacknowledged question is to how the possibility of forking interacts with the critique of meritocracy in organizations in general, and specifically what that means for community inclusiveness as a goal in open source communities. I don’t think it’s straightforward.

Note: Nick Doty has written a nice response to this on his blog.

Leave a comment
May 24, 2018

Inequality perceived through implicit factor analysis and its implications for emergent social forms

Vox published an interview with Keith Payne, author of The Broken Ladder.

My understanding is that the thesis of the book is that income inequality has a measurable effect on public health, especially certain kinds of chronic illnesses. The proposed mechanism for this effect is the psychological state of those perceiving themselves to be relatively worse off. This is a hardwired mechanism, it would seem, and one that is being turned on more and more by socioeconomic conditions today.

I’m happy to take this argument for granted until I hear otherwise. I’m interested in (and am jotting notes down here, not having read the book) the physics of this mechanism. It’s part of a larger puzzle about social forms, emergent social properties, and factor analysis that I’ve written about it some other posts.

Here’s the idea: income inequality is a very specific kind of social metric and not one that is easy to directly perceive. Measuring it from tax records, which short be straightforward, is fraught with technicalities. Therefore, it is highly implausible that direct perception of this metric is what causes the psychological impact of inequality.

Therefore, there must be one or more mediating factors between income inequality as an economic fact and psychological inequality as a mental phenomenon. Let’s suppose–because it’s actually what we should see as a ‘null hypothesis’–that there are many, many factors linking these phenomena. Some may be common causes of income inequality and psychological inequality, such as entrenched forms of social inequality that prevent equal access to resources and are internalized somehow. Others may be direct perception of the impact of inequality, such as seeing other people flying in higher class seats, or (ahem) hearing other people talk about flying at all. And yet we seem comfortable deriving from this very complex mess a generalized sense of inequality and its impact, and now that’s one of the most pressing political topics today.

I want to argue that when a person perceives inequality in a general way, they are in effect performing a kind of factor analysis on their perceptions of other people. When we compare ourselves with others, we can do so on a large number of dimensions. Cognitively, we can’t grok all of it–we have to reduce the feature space, and so we come to understand the world through a few blunt indicators that combine many other correlated data points into one.

These blunt categories can suggest that there is structure in the world that isn’t really there, but rather is an artifact of constraints on human perception and cognition. In other words, downward causation would happen in part through a dimensionality reduction of social perception.

On the other hand, if those constraints are regular enough, they may in turn impose a kind of structure on the social world (upward causation). If downward causation and upward causation reinforced each other, then that would create some stable social conditions. But there’s also no guarantee that stable social perceptions en masse track the real conditions. There may be systematic biases.

I’m not sure where this line of inquiry goes, to be honest. It needs more work.

Leave a comment