ehmke-contributor_covenant.md 30 KB
title: "Coraline Ada Ehmke: Contributor Covenant" narrator: Coraline Ada Ehmke subject: Contributor Covenant facilitator: Nathan Schneider date: October 10, 2024 approved: October 11, 2024 summary: "After widespread resistance to codes of conduct in open-source software communities, Coraline Ada Ehmke's Contributor Covenant became the most popular code of conduct in the ecosystem."
tags: [code of conduct, dispute resolution, gender, open-source software, organizations]
First of all, I want to begin with the question of how you how you prefer to introduce yourself.
My name is Coraline Ada Ehmke. I'm the founder and executive director of the Organization for Ethical Source. I'm also a software engineer, emerita, having spent about two and a half decades in the industry. I'm best known as the creator of Contributor Covenant, the first and most popular code of conduct in the world for open source communities and other digital communities. And I'm very happy to be here with you, Nathan.
How would you outline the trajectory of your life and career? Where do you start? And where are you now?
Career-wise, I would start in 1994, when I was a kind of adrift kind of kid. I was working at an engineering company in Austin, Texas, because my girlfriend got her dad to give me a job there. Back then I'm a smoker, and I'm always having conversations with the other smokers, who, some of whom are software engineers and some of whom are IT folks. So I have a good relationship with them. And one day one of them comes up to me and says, "Coraline, did you hear the company's putting together a web team?" I was like, "Oh, that's amazing. Put the company on the Internet. That's great." And he said, "So what do you think that's going to do for your career?" And that is how I fell into software development as a college dropout.
Then fast forward a lot of years to about 2012, 2013. This is the point where I had made a decision to begin my gender transition. I was slowly waking up to realities of the world that had been conveniently easily ignored by me previously, and that were no longer ignorable. Things that I understood in principle, I was beginning to experience firsthand, and that made me angry. But it was a righteous fury, and I decided to look for ways that I could use my skills and my life experience to change things, change the world, change the sphere that I was operating in---the sphere of tech and the sphere of open source---to make it less awful for people. And over time I've graduated from less awful to actually, like, maybe pro-social. Maybe we can use technology to actually make a difference in the world, a positive difference in the world. So I am less righteous fury these days, and more hopeful, looking for visions of equitable futures. I guess that's my career in a nutshell.
Does the does the world word "protocol" mean anything to you? Is that a word that you've used to describe aspects of your life, or that has been an important part of your work?
It is, in multiple senses of the word. Back in the day I was giving a talk called "He Doesn't Work Here Anymore," which was about my experience of transitioning as an engineer, as a technologist. One of the things I pointed out was that I was learning that communication works very differently than the way I'd experienced it in the past. If you likened it to the HTTP protocol, women were including extra headers that indicated the kind of response that they were hoping to get by sharing a particular by communicating a certain thing. Men on the receiving end were ignoring those headers and answering in a way that was maybe solving a problem or something, but not what was wanted. Other women are sensitive to these headers that are embedded in the messages, and communicate more empathetically for that reason. I was using the HTTP protocol as a metaphor for humans communicating. So I think I've always had the notion of a protocol as a methodology for interactions, whether between human agents or pieces of code.
I love that you brought up that context, and it reminds me, too, of the what you said earlier about the way in which things become visible in the context of transition. Things that are invisible otherwise visibilize themselves. And you know that, I think, is part of the behavior of protocols---to be invisible as infrastructures, and then to become visible when some kind of the inadequacy becomes clear.
Sure, or a bad implementation. That's always a possibility as well. A protocol is only as good as its adaptations.
You identified earlier with the Contributor Covenant. I wanted to focus this conversation as well, but feel free to bring in other projects as well, because I think other projects of yours are relevant. But starting with the Contributor Covenant, can you describe the story of your motivation for developing and then stewarding it, especially for people who are not familiar with what it is. Where did that story start for you?
It was around 2013, I believe, 2013 or 2014, when a Twitter hashtag emerged from the Python [programming language] community, which was #COCPledge. Basically, conference speakers were pledging to not speak at conferences that didn't have an enforceable code of conduct. This is a time when we have a lot of new people coming into the industry, a lot of people who have seen the salaries that tech companies offer and can see the transformative power of being involved in that economy. And a lot of those people didn't look like the people who came before them. And a lot of those people faced challenges that the people who came before them didn't experience. Those challenges could seem invisible. So codes of conduct were becoming necessary for the peaceful operation of gatherings of technologists. But that was meeting with resistance. It was very controversial. This is something we take for granted now---even department stores have codes of conduct now. But it was very controversial at the time for conferences, and there was a lot of a lot of activism that was required to make it a norm.
In the midst of that, I saw that there are other places where technologists gathered, where their conduct also had the potential to be problematic. This was on Github, in the context of our open source communities and projects. The concept of a "community" was beginning to come into common usage to describe the group of people that coalesced around an open source project, and was not always a given. As we began to see projects as communities, we saw the need for shared values and norms to emerge. This led to the philosophy behind the Contributor Covenant, which was written as a way to establish shared values and norms for how people would interact in these open source communities. Over time, our understanding of what this means has developed and matured, and the Contributor Covenant has become a living document. The team is currently working on the tenth anniversary version 3.0, which will be modular to accommodate the novel use cases they've discovered, such as Discord servers, Slack communities, and even offline events. This evolution towards an "adapt versus adopt" approach is another way the concept of codes of conduct for digital communities is maturing to meet changing needs. The Contributor Covenant has always been a living document, accepting pull requests and being translated into more than twenty-five languages. With Contributor Covenant 3.0, the team is looking to expand their coverage of languages from the global south, in an effort to counteract the export of white western values that often go along with open source by default, and to be a force for decolonization. They have big plans for what a more globally oriented, norm-based instrument can do for the world.
So, in telling that story, you began in passive voice---it was created---and then you switched to first-person plural. I wonder if you could describe a bit more about the design process for the Contributor Covenant at each stage? From the beginning, what was that process like and how has it evolved now?
Wow! That's a great question and a great observation. At the beginning, the Contributor Covenant was very much a social justice manifesto, and many critics of codes of conduct in general, and the Contributor Covenant in particular, regarded it as a political document pushing a certain political agenda. I was in full agreement with these critics that yes, the Contributor Covenant was attached to a social justice agenda. And why shouldn't it be? It was very confrontational, and the language was also confrontational, because they were confronting a status quo and a culture that was literally harmful. Of course, what they proposed was antagonistic and confrontational, because that was the context in which they were operating.
Over time, however, the Contributor Covenant has gotten less confrontational and less adversarial, and more reflective. I hope it is more reflective of changing values in our digital communities as well. With version 3.0, the emphasis is on the globalization of the Contributor Covenant as an instrument. To achieve this, we actually have to strip out a lot of the language that would typically be associated with some of the values they're talking about, because it's jargon---social justice jargon. When talking to people who don't speak English as a first language, or people who are from outside the white Western sphere, those words aren't going to make sense to them, and that's not acceptable anymore.
Was it a collective project from the beginning?
No, it was just me shepherding it, guiding it, and writing it for a number of years. I gifted contributor Covenant to OES, I believe, in 2021 or 2022.
The Organization for Ethical Source.
Yes, I gifted the Contributor Covenant to the Organization for Ethical Source because I saw that it was too important to be under the control of just one person. I didn't want there to be a single person responsible for it.
There was a GOVERNANCE.md file that got added to the Contributor Covenant at one point in time, and I used CommunityRule to put it together. I established myself as a "benevolent dictator for life," at least for now. But when I did that, it didn't feel right, it didn't sit right. I was like, "Why should I have complete authority over this document that is influencing tens or hundreds of thousands of developers daily?" That's a big responsibility, and maybe I'm not qualified to shepherd that forever.
Bringing it to the organization and bringing it to a community of ethics-minded technologists---that made a lot of sense. And it made sense as a legacy. You have to plan for what happens when you're not around to do the work anymore. It just made sense, and it felt like the right time.
Why do you think you chose to go in the direction of a code like this? I mean, you could imagine people have taken a lot of different approaches to tech in, or ethics in tech---whether it's litigation or advocacy, petition-signing, or passing laws in governments, or working to change policies within companies. Why did this medium stand out to you as the tool you could use?
There's precedent for codes of conduct as an instrument for setting norms, studying shared norms, and defining shared norms. So a code of conduct as an instrument made a lot of sense to me.
There's a reason it's called the Contributor Covenant instead of the Contributor Code of Conduct. It could be the Contributor Code of Conduct very easily, which would be more descriptive. But it's more about a situation when I am entering a space, I'm entering a community space, and that community is telling me what it values, and that community is telling me what is acceptable and what is not acceptable. We're entering into an agreement, we're entering into a social contract together, where these will be the norms that govern how I interact with you and how you interact with me.
It's adopting a protocol, and that just made a lot more sense than a list of rules or regulations, or policies or manifestos. Not to say that those things don't have value, not to say that those things aren't related or interdependent. But it just makes sense to me as a really general, well-recognized form of social contract.
Can you talk me through the way it functions? I think this connects to the distinction between code and covenant. How does it work? Maybe in an example or in general practice that you've seen? How does this function in the world?
The Contributor Covenant begins with a preamble which is basically a list of protected classes from a human rights perspective. This establishes the intent right off the bat---it's saying we are intending our community to recognize, understand, and remediate issues that people who fit these criteria often experience. So first of all, we're prioritizing the safety of the most vulnerable and those with the least agency. We're saying that right from the beginning.
Everything beyond that point is details. Next, we have a list of behaviors---behaviors that contribute positively to the community, and behaviors that contribute negatively to the community. We give examples of positive, pro-social behaviors, and we give examples of antisocial behaviors, as a way of painting a picture and domesticating the high-level statement of values. How does this get put into practice? How do we treat each other? It's almost contractualism---what do we owe each other?
From there, we go into some procedures around how to report a violation, and what kind of pledges the community managers or community leaders are making in terms of equitable enforcement. With version 2, we added a note that I think should have been implicit, but we made it explicit---that these things require human judgment, they require discernment, and that was also the purview of the moderators, to feel free and to exercise responsibly that aspect of responsibility. They had to use their best judgment and acknowledge that they're human and flawed, and that's okay.
At the end, we're hinting that we want people to adapt, not just adopt, by saying this code of conduct is adapted from the Contributor Covenant, with a link to the permanent URL. We're going to make that a little bit more explicit with Contributor Covenant 3.0, but that's basically how it works. It's setting up, "Here's what we value, here's how we treat each other, here's what we do in case of conflict." At a high level, that's the purpose of a lot of governance documents. Right? Here's what we value. Here's how we treat each other. Here's how we operate. Here's why. And here's how.
How has this been adopted in practice? It's gone from being an insurgent project that encountered a lot of resistance, as you said, to becoming really widespread in the open source world. What kinds of doors opened? Were there particular moments you think of that revealed something about how the protocol was working?
In the beginning, say for the first 5-6 years, the presence of a code of conduct was a signal that the project leaders, the community leaders, cared about these shared values, had the intention of making their community welcoming and safe. However, with the widespread adoption of codes of conduct, it's become something that people don't think too much about until they have to. It has also become less of a signal, because the adoption is less intentional. Now, the reverse is true. A project without a code of conduct is a stronger signal than a project with one.
In a sense, this is a victory, because we have normalized something that once was an impetus for death threats. But at the same time, it calls attention to the fact that we can't be complacent about something as important as our values, or our protocols for interacting with each other in an equitable way. This is something that has to be actively worked on, actively developed, actively paid attention to and actively checked in on from time to time.
Our relationship with equity has changed and gotten a little bit more complicated, and maybe a little bit more demanding. But the same could be said of governance across the board in digital communities---it requires a lot more work now than it did ten years ago. This is the reality we're facing, and it's something that needs to be continuously addressed and improved upon.
Have you had experiences of capture? When, for instance, has the covenant been used in ways that you didn't expect, and that you objected to?
I've had questions about why certain communities have adopted it---communities whose work I think is not necessarily terribly pro-social. I've had mixed feelings about big adoptions by FAANG companies, for example. Facebook, Apple, Amazon, Netflix, Google. There have been companies whose business models are predicated on human rights abuses. I have mixed feelings about them using Contributor Covenant. But the way I reconcile it is that a lot of developers, a lot of technologists, and others are going to be interacting with the open source projects that these companies put out. I care more about the experience and equitable treatment of the people who are in a position where they are interacting with those projects, maybe because they have to. I care more about them than I care about Facebook itself, for instance. So objecting to Facebook's adoption would be negatively impactful on the tens of thousands of developers who use their frameworks.
Referring to these companies makes me wonder about the question of economy. You've more recently worked to build an organization around this around this work. But what has been the experience so far around supporting the work that goes into developing this project? Was there funding at the beginning? What kind of economic journey has this project been on?
The Organization for Ethical Source was founded with a grant from Omidyar, in conjunction with a partner organization. This interest was sparked by our work on the Hippocratic License, the Ethical Open Source license that's tied to the United Nations Declaration of Human Rights.
I would say that the majority of OES's funding since 2020 has been because of philanthropic interest in ethical licensure. Meanwhile, the industry is not yet ready for ethical licensure, and there is still work to be done in that domain.
As OES has tried to expand beyond licensing to paint a more holistic picture of governance and norms-based instruments that match every step in the life cycle of an open source technology, there has been less interest in that. We actually applied to an organization based in Germany that funds open source projects, the Sovereign Tech Fund. And we've applied to other places for funding specifically for the Contributor Covenant as well, but the desire for that funding just isn't there. This has been pretty frustrating.
I think it might be because the Contributor Covenant is now something that's taken for granted. People understand the work that remains to be done, but from a funding perspective, the Contributor Covenant has been a disaster. The only support we've had is some donations from the community, but we've never seen a donation or any kind of material support from any of the FAANG companies that have adopted our code of conduct. Nine out of the ten largest open source projects in the world have adopted the Contributor Covenant, and nobody pays those maintainers. So we're certainly not in it for the money or the attention it gets from funders.
This has been a challenge, but luckily the Organization for Ethical Source is scrappy and we're volunteer-led, so we're not going to let that stop us.
What have been some of the most important and material tasks or decisions over the course of the project? Were there particular pivot points?
The addition of the Enforcement Guidelines were a pretty big milestone for the Contributor Covenant. A lot of the critiques people had were around codes of conduct being very divisive, as I mentioned from the get-go. And while sometimes those opinions were expressed through violence and threats of violence, I always tried to listen to what people were saying behind those threats, to understand what they were afraid of and see if there was anything I could do to make them less afraid.
One of the things we saw a lot on 4chan, 8chan, and other similar forums was this attitude that "I'll say one thing wrong and I'll be kicked out forever." This always struck me as really odd, because if a project maintainer would do that, why would people be trusting them at all in the first place, if they thought the maintainer was that unreasonable? But this was a very loudly expressed fear---that if someone says something that's politically incorrect, even accidentally, they'll be banned for life.
The addition of the Enforcement Guidelines was meant to address concerns like this, to make the process more transparent and less arbitrary. It was an important milestone in trying to allay those fears and make the Contributor Covenant more effective and accepted. So we decided to include Enforcement Guidelines, which were based on the enforcement ladder approach used by Mozilla. The idea was that different types of code of conduct violations would warrant different enforcement actions, ranging from minor to major consequences. The response would not be the same for someone who casually made a mistake versus someone who was trolling or being aggressively offensive towards another community member.
Including the Enforcement Guidelines seemed to address a lot of the feedback and fears that people had expressed. This did open up a period of "rules lawyering," where people were still arguing that too much authority was given to project maintainers. However, I pointed out that project maintainers had always had the ability to remove anyone from the project for any reason, arbitrarily, regardless of whether there was a code of conduct in place.
Despite this pushback and even vitriol, I've tried to adapt to the changing conditions and demonstrate that, despite the Contributor Covenant's social justice origins, the underlying social justice concepts are pro-social and should not be controversial. I'm not asking someone to adopt an entire political agenda---I'm simply asking them not to discriminate against others and to treat each other as fellow human beings.
You mentioned the license licensure work, the work with the ethical source licenses. Could you say a bit about how that next phase of protocol development came about for you?
The impetus for creating the Hippocratic License 1.0, or even the alpha version that got so much attention in 2019, came from Mijente, the Latinx activist organization and immigrants' rights activist organization, and their "No Tech for ICE" campaign. This highlighted the issue for us. We saw that open source was being used and abused in ways that the open source community wouldn't accept, like an individual maintainer's software being used in extrajudicial killings. At least, we hoped they would be opposed to something like that.
It seemed like a clash between values, where we had organizations like ICE using technology, very visibly, to commit human rights atrocities. And I was like, we have no means of defending our technology from these abuses. What can we do? And licensing, this is a fundamental hack that open source is based on, or was originally based on.
So the idea came up for a license where we're saying, "No, you're free to use, you're free to fork, you're free to do everything you can do with an open source project, except commit human rights violations." And that was a bridge too far for open source traditionalists, who insist on "Freedom 0"---that the open source technology can be used for any purpose whatsoever without any restrictions at all.
The thing that struck me about that is that it extends software freedom to freedom that stops at someone who's capable of reading and writing code. But I think software freedom should go all the way down to people upon whom technology is used without consent---the entire ethical supply chain, if you will. And that's a point of contention between practitioners of open source who are ethically minded, and practitioners of open source who are more traditional and more narrow in their interpretation of what "open" really means.
That's something we've contended with, and we've tried to address critiques of ethical licensure, especially in terms of enforceability, which I think we've satisfied pretty well now. This is an evolving field and an experiment. I think it's really interesting, and it's done a lot of good so far.
The Hippocratic License has actually become very popular---the most popular sector of adopters is academic researchers. That's fascinating to me, even though it's not the intended use case we had in mind. It's really interesting to see what's happening with it in the real world.
You talked about the enforcement there, and that's a point of contrast between the two designs. Right? The Contributor Covenant relies largely on the assumption that there's either an organization or a maintainer, somebody who is exercising a kind of community-scale enforcement power, and they have the ability to remove people, whereas the the Hippocratic license, the ethical source licenses, rely on a level of legal enforcement. Can you say a bit about how that that kind of dependency, so to speak, affects the design of the protocol?
One of the key goals for the Ethical Source licenses that aligns perfectly with the Contributor Covenant's framework is to make the implicit explicit. The team wanted to ensure that the rights extended to the most vulnerable. Just like in the preamble of the Contributor Covenant, they are calling out specific protected classes as a priority for their community. The Hippocratic Code License 3 introduced an interesting provision on the enforcement side, which a lawyer would call a "supply chain impacted provision." This provision essentially states that if Facebook uses the code licensed under the Hippocratic License, and the use of that code results in human rights violations against a specific population, that population has the right to sue Facebook for damages. This inverts the power, giving the impacted people the opportunity to pursue legal action, which corporations would have to take seriously. As a maintainer of a JavaScript library, they would not sue Facebook for infringement of someone else's human rights. It wouldn't work. But if the people upon whom facial recognition software is used and abused choose to file a class-action lawsuit, that's something very different.
Licenses are the intersection of open source communities and corporations or institutions. Institutions can't be held to ethical standards that depend on their goodwill. Institutions have a different set of incentives than people do, and therefore the norms that we are establishing have to be incentivized differently. That means relying on legal regulation.
The question of incentives has been running throughout the conversation. I hear that also in what you were describing about the signaling power of the Contributor Covenant. How much of that kind of thinking went into the design process explicitly? Or is it more a matter of observation after the fact?
II would say it was after the fact. I started writing Contributor Covenant in a moment of inspiration and a desire for righteous retribution. I was riled up by the state of the world and wanted to make a big impact and a big change in the way things were done.
But things have changed since then, and I've become more deliberative. Now that we have an org, we're very deliberative, doing more strategic thinking and less reactionary stuff. And that's just the natural evolution of a project like this. We're still staying true to our roots, of course, and to the values that inspired the original version. But the technosocial context has changed, and we have to adapt with it. What worked at the beginning won't work anymore. And that reflects our changing way of maintaining it. I hope that answers your question.
Yes, thank you. Finally, I'm curious about earlier legacies. You've talked in the context of the Contributor Covenant about earlier codes of conduct and with the licenses about the way open source in general is built on that foundation of licensing. But are there other kinds of precedents that you think of, that informed your motivation and your designs?
When I look back on it, I wouldn't say that there were specific things that directly inspired the language of Contributor Covenant 1.0 beyond fluency and the concepts. But in retrospect, I guess the circles I was moving in had more explicit norms.
As a Gen Xer, I think we take a lot for granted. But through my interactions with later generations of technologists, I've found that people are more explicit about expressing boundaries verbally, introducing themselves, acknowledging their disabilities, and other norms that didn't happen when I was coming up. So the fact that these are norms with newer generations of technologists is inspiring and definitely influences what we're doing. It reminds us why we're trying to make the invisible visible and be open to different ways of expression and interaction as the world moves on. We have to adapt, you know?
Is there anything else you want to bring up before we wrap up?
Some protocols are very long-lived, and my favorite example is the MIDI protocol. It was established in 1983 and has only gone through one major revision, which was backwards compatible.
I think the most effective and long-lived protocols make the fewest assumptions, are the most explicit, and are just as simple as the complexity of their domain will allow them to be. And I think we can take inspiration from those aspects of successful technical protocols and apply them to social, interpersonal protocols as well.
Is there a danger, though, in that narrowness of a tightly defined protocol, in the context of social protocols?
You just want to make sure that the protocol is capable of expressing the things that need to be expressed. Simplicity is not necessarily the same as filtering or losing data or losing resolution, or anything like that. The messages can be very rich, meaning the activities can be very rich. What's passing through the protocol can be very rich, even with a simple protocol. Telephones operate on that principle. Telephones don't care what you say, but they're gonna get that voice communication across the wire right.
Yeah, or the modem communication across the wire. You can do all sorts of things.
And that's the beauty of protocols: they're fundamental and they become infrastructure---if they're effective, they become infrastructure. Not to say that we don't want to pay attention to them. They require maintenance. All infrastructure requires maintenance. But you're successful when it becomes when it becomes a normal way of doing things.