Back in May, I decided to leave the LLVM project, to which I was a contributor. I announced this decision in an open letter to my colleagues, which received some coverage in the technical press at the time, and a number of requests for further comment, which I declined. In what follows, I want to elaborate upon my reasons for leaving and explain what I think is going wrong in open source generally, and at LLVM in particular.
First, for those unfamiliar with the tech world, a little background. Software is commonly developed and made available to the public in one of two ways: either proprietary software is developed privately inside a company and sold for a fee, or open source software, as the name implies, is developed in the open for anyone to use and improve. Microsoft’s Office is an example of the former, and the Linux operating system is an example of the latter.
Among programmers, there are ongoing discussions about the advantages and disadvantages of both models. I have been attracted to the open source side of this debate since I started university, the most appealing aspect of which was the greater potential to do good. Only one company can improve on proprietary software, and only that company’s customers can use it. With the same effort I could write open source software and make it available to everyone.
Having developed software in both models, I now realize that another big advantage of open source is the development community. Because software is developed in the space between companies, the corporate politics of each company is avoided, and developers working for different employers can normally cooperate more freely. This was, until recently, a geek’s paradise. Open source is old, but it grew rapidly during the early days of the internet, back when it was used to be said that, “On the Internet, nobody knows you’re a dog.” It didn’t matter who you were, all that mattered was the quality of the work you produced.
In 2006, LLVM was the first open source project I managed to work on full time, shortly after leaving university. I was hooked. From that day forward, I always tried to ensure that if it wasn’t my job it would still be my hobby. I have moved companies and countries many times since, but I’ve always looked for jobs where I would have the opportunity to work in LLVM. LLVM is mainly a tool for other developers. As such, it may seem a bit esoteric to those not involved in software development. It also means that there are a lot of indirect users, including iPhone and Android. The combination of a meaningful but obscure area of work was exciting and rewarding, and as the years passed, I became one of LLVM’s most active developers.
Unfortunately, the environment changed fairly quickly. First, with the adoption of a code of conduct, and then with the introduction of policies that promoted discrimination in the name of ‘diversity.’ It is easier to start with the second of these issues, which was also the one that convinced me to leave.
Over the summer months, it is common for open source projects to recruit students as interns. The main contributor to this scheme is Google’s ‘Summer of Code,’ which has been sponsoring student internships for 13 years. This is an invaluable initiative and I am proud to have mentored a student myself in the past.
This time around, however, the LLVM foundation decided to pay for an internship themselves, and agreed a partnership with an organization called Outreachy. This collaboration saw LLVM adopt interesting new eligibility criteria. Outreachy’s rules state that an applicant must “meet one of the following criteria”:
- You live any where in the world and you identify as a woman (cis or trans), trans man, or genderqueer person (including genderfluid or genderfree).
- You live in the United States or you are a U.S. national or permanent resident living aboard, AND you are a person of any gender who is Black/African American, Hispanic/Latin@ [sic], Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander
What is the problem with that? Isn’t diversity something we should incentivize? As it happens, I don’t think diversity is either inherently good or inherently bad. Rather, it is normally an indicator of something good. For example, if it is desirable to live in a particular country and that country is open to newcomers, immigration will naturally make it diverse as a consequence. I have personally benefited from openness when moving from Brazil to Ireland and from Ireland to Canada. When I left Brazil, my original intention was to move to the US, but the quotas operative in the US immigration system are the reason I went to Ireland instead. When I moved again, I opted for the Canadian permanent residency program over the US green card.
The same principle applies to open source. No one has to pass an interview or physically relocate to work in open source, so it attracts more people than a corresponding proprietary software position. Had LLVM been proprietary, a new graduate from Brazil like myself would have found it impossible to get involved. So, I think it is evident that reducing barriers to entry is a good thing. It is also likely to increase diversity. In the absence of obstacles, all that matters is the willingness and ability of each individual. That is a noble meritocratic goal.
Problems arise, however, when objectives are confused with indicators. A similar confusion occurs in other areas. In economics, it is known as ‘Goodhart’s Law‘: “When a measure becomes a target, it ceases to be a good measure.” In the case of diversity, this confusion is particularly unfortunate. The use of discrimination to meet quotas at the expense of merit is exactly the opposite of what made diversity initiatives laudable in the first place.
The tech industry in general has, by now, travelled a considerable distance down the discrimination-for-diversity path. According to the Wilberg v. Google lawsuit, recruiters were given quotas to meet for different ethnic groups. Finding a suitable candidate to fill a technical position is hard work. Were I starting out now, I would worry that a recruiter might hire me to help fill a quota on the basis of my name alone, rather than on the basis of my abilities.
Even if one is inclined to agree with discrimination in the name of diversity, the particular criteria used by Outreachy are still rather odd. Why is it sufficient to identify as a woman, but necessary to be Black, Hispanic, or some other favored demographic? And why is the US a special case? Is a Hispanic living in the US more deserving than a Mexican born and raised in Guadalajara or Tijuana?
The adoption of Outreachy’s bizarre new eligibility rules compounded the problems already associated with LLVM’s recently floated Code of Conduct, which I oppose mainly because it also correlates with discrimination. Most Codes of Conduct look a lot alike. As far as I can tell, one of the earliest templates was the explicitly discriminatory (and now discontinued) code introduced by the TODO group, which stated, among other things, that, “We will not act on complaints regarding: ‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’.”
That prototype was subsequently popularized when it was adopted by GitHub. From there, it has spread, with some variations, to a number of other projects. While the explicitly discriminatory language has been dropped in some instances, including the version adopted by the LLVM project, it nonetheless lingers in spirit. The LLVM code reassures participants that, “We strive to be a community that welcomes and supports people of all backgrounds and identities.” One would hope that blocking someone from an internship based on their skin color or sex would then not be acceptable. In practice, however, the same people pushed for both the code of conduct and for Outreachy’s involvement.
There are also a number of smaller, but still serious, issues with the letter of the proposed Code of Conduct. Not least among these is its scope. The LLVM version of the code explicitly extends the project’s authority to the lives of its members outside the workplace: “Violations of this code outside these spaces may, in rare cases, affect a person’s ability to participate within them.” Other variants of this warning are not as explicit, but the failure to delimit the scope of the code’s authority makes it dangerously ambiguous. Which cases? And how rarely? Participants are not told.
One of the problems with this kind of careful ambiguity is that we are living in an era in which those who warn of the dangers of tribalism (eg: Jordan Peterson) or Islamism (eg: Maajid Nawaz) can find themselves in serious trouble as a result. Can we be sure that either of these individuals would be accepted into a community instead of being excluded for being ‘disrespectful’?
Open source projects were, in my experience, already some of the most welcoming and inclusive environments in which to work. Even if we concede that an explicitly worded Code of Conduct is desirable, it is essential that its scope is clearly defined. It is, for example, perfectly possible for pro-life and pro-choice advocates to collaborate on a software project. They just have to leave their opinions about abortion at the door, and this should not preclude them from freely sharing those opinions on social media without fear of disciplinary reprisal. In this way, rules can be made simpler and stricter: the spaces provided by the project are only for discussions relevant to the project, and what goes on outside the workplace is not our concern.
For a few years now the idea that one should “Bring Your Whole Self to Work” has been popular in tech circles. But it now seems that when we do this, work tries to enforce what that “whole self” ought to be. This will not result in an increase in diversity. To the contrary, it will produce an atmosphere of stifling conformity.