Drew DeVault – Building and scaling Hare's community governance #FOSSBack

In this talk, Drew DeVault discusses the governance of the Hare programming language project, which is focused on building a community around reliable, stable software development. The speaker emphasizes the importance of a strong culture and shared values among the project's 12 maintainers and 140 contributors, highlighting the social aspects of open source development. DeVault outlines the project's governance structure, which includes an informal request for comments (RFC) process for making technical decisions and a code of conduct adapted to promote inclusivity and safety within the community. Key to their governance approach is the belief that power and responsibility are shared among all contributors, fostering a sense of ownership and empowerment. DeVault also shares insights on how they address challenges within the community and the measures in place to encourage positive interactions. Ultimately, he asserts that the success of the project is rooted in recognizing the personal investments of all members and building a collaborative environment.

Uh thanks everybody for coming. So uh I'll just introduce myself briefly. My name is Drew DeVault. I work for a company called Sourcehut that produces 100% free and open source software to build a software forge. And we also uh use our revenue to support open source projects that we want to work on, uh including the Hare programming language, which is what I'll be talking to you about

today. Uh just up front, I have a QR code here. If anybody has accessibility needs to follow along with the slides on their phone, maybe that's easier for you. There's also some links throughout the slide deck that you might want to click through. Uh go ahead and download the PDF here so you can follow along. So uh this is our mascot, the beautiful Harriet, uh drawn by

my friend Lewis. Uh you might have seen the stickers outside. If you've already put these adorable stickers on your laptop uh without knowing what it is, I'm proud to welcome you to the uh propaganda arm of the Hare programming language. Uh so what is the Hare programming language? Uh my talk is not really about that. My talk is about how we govern ourselves, but I'll introduce it

briefly. Uh Hare is a systems programming language, and we prioritize stability. Uh kind of like a radical stability even. Uh we want to be somewhat boring, but also reliable and stable for a very long time, which is something that I think distinguishes us from a lot of other programming languages and programming environments where there's a lot more churn. This is something we're trying to work against as

we build our project. But again, the actual language is not what I'm here to talk about. I'm here to talk about how we govern ourselves. What's most important about what Hare is is Hare is a group of people who are working on a common project. And we're working together not only to build the software that we want to build, but also to build a community. We are

12 maintainers, and the last time I counted there was about 140 contributors in total. It's a relatively small community by the standards of many of the projects represented here today. Uh but it's also uh in addition to the software project, it's focal point of all of our social graphs. We have friends that we've developed through this project, people that we work with directly in the project, and

also people that we liaise with, like the people running Linux distributions who package our software, for example. So the important thing to acknowledge about a project like this is not just the code, but also the position it holds within our lives, and to use this as the basis of a good governance model that starts with acknowledging the social aspect of the project. And that's important because what

it reveals to you is that everybody involved has a stake in the project. This little bit of their blood, sweat, and tears that they've put into this community is the basis of good governance. It starts by acknowledging that stake, and acknowledging that it comes with responsibilities, and it comes with a sense of empowerment, or even entitlement, in this case legitimate entitlement, to participate in how the community

is run. So Hare is licensed with a copyleft software license. We use a combination of the GPL and the Mozilla public license, both of which are copyleft. And we don't include a contributor license agreement or any form of copyright assignment, which means that the software we're building literally and legally belongs to all of the contributors to that software. And it's important to kind of reject this auteur

theory of software, where we believe that because we started the project or because we're the commercial storers of the project that it belongs to us. But it doesn't. It belongs to our uh philosophically in all open source projects, but also for Hare legally. And it's important to recognize that when we think about how we're going to govern ourselves and what sorts of and what sort of privileges

uh the community is going to be responsible for. The product of our collective investment is what I like to say open source is. So how do we contribute to the Hare programming Um I want to point out that there are a few different ways of doing this. I'm sure many people have already had the sort of internal moment of reflection where you've realized that there's more more

to it than just writing the code, but of course there's writing the code, and then there's also participating in the community, discussing the programming language on forums, uh writing blog posts about it to evangelize the project, building projects and libraries that enrich the ecosystem. But this is sort of a tangible and active way to contribute to the project, but I also want to acknowledge the more intangible

and passive ways that we contribute to the project, and that's particularly with the way we conduct ourselves and the way we treat each other. Uh we want to create a community where we're making a conscious choice to welcome new people into the community. And by doing this, we are reinforcing all of the ways that people contribute to the project. And most importantly, we're trying to make new

people not only get them familiarized with the code base and with the documentation, get them productive, but also get them personally invested in the project and make them feel like it belongs to them, too. Now beyond the philosophy, let me talk a little bit about how we actually uh govern ourselves when it gets down to brass tacks. I'm going to outline the history of our governance models

and of the way the project community was built. And I'm also going to discuss the formal mechanisms that we use to govern ourselves. But I want to emphasize that what I've talked about up till now, the more philosophical view, is the more important component than any of these formal processes. We try to use the tools that we have as little as possible and rely instead on good

cultures and good shared values to keep our community running smoothly. But let me talk about the actual tools we have. First of all, we have now adopted an informal RFC process, request for comments, which I'll talk about a little bit later in more detail, to make the big technical decisions. We've also adopted a code of conduct, as many projects have. Although we've made some changes to the

way that most projects adopt a code of conduct, I'll elaborate on those as well. We have a fiscal policy, which barely ever comes up. We have some money in the bank. Obviously, we don't want the the drive-by contributor to have access to the bank account, so we needed to have a policy for how to use it. And we have a benevolent dictator for life. Hello. Which we

use only when all else fails. Again, the goal is to use these tools as little as possible. And we do use them as little as possible. We get an average of one RFC per month, maybe. Most of the the software development doesn't require one. Uh conduct issues are rare. I have a list of case studies, which actually exhaustively covers all of the times the code of conduct

has been enforced in this talk. And mostly we operate on a principle of informal consensus building. So let me talk about the history of the project and how we've uh organized In December of 2019, I started working on the Hare project in secret. Uh and I I just talked about it with my close friends and people that I already knew in social IRC channels I was in,

small spaces, just saying, "Hey, I'm working on this. What are you guys working on? Let's share the things we're doing." Ordinary dinner table conversation. That's as far as it went for a while. But then a few months later, I started teasing what I was working on on my blog. I At the time I used to publish monthly status updates of what I was working on on my

blog, and I started to uh drop hints that I was working on something secret, then I started to elaborate it was kind of a programming language I was working on. And at this point, the governance model became something like an augmented reality game. Uh because while I was working privately, none of the actual resources, like the source code repository, the mailing list, the IRC channel, were private.

And if you knew where to look, you could find them. It started kind of an Easter egg hunt. First person to win this Easter egg hunt was Amber Sawatari, uh who has since become one of the co-maintainers of the Uh she sent her first patch after she discovered the project through the public uh continuous integration build logs. And now at this point, uh the governance model is

sort of evolving a little bit. It's still mainly the classic BDFL approach, uh but because the project is secret and it has this kind of element of discovery that's involved in getting to it, uh I have the opportunity to onboard every contributor one by one with a high-touch approach. So every time somebody stumbles into the project and introduce themselves, this is maybe one person every month, every

other month, who shows up, who I have an opportunity to communicate our culture to, our values to, what we're trying to accomplish in a one-to-one manner that is really a privilege that a lot of open source projects don't have. And that was really really powerful for building the kind of community that I wanted to see here. And at this point, we're also, you know, working on the

code itself. At this point, we start rewriting the compiler, uh start working on the standard library, and eventually we get to April of 2022. Now this is about 2 years on. There's 18 people in total who have worked on the language while it was in its sort of secret phase. and each one of those are people that I know personally at this point and have had a

lot of time to get to know, and together we've decided who we want to be, what our community should be. And when this project is introduced to the public, we've preceded this community with 18 people who all know each other and understand the community and the values we want to have and can communicate them onwards. We have a core group of really well-educated, on-boarded people who know

what we're about, who know how decisions are made, and who can help new contributors get involved, but also understand what our values are and what we're trying to do here. And at this point, the governance model is firmly a BDFL model, except with lots of trust going around between contributors. Decisions that need to be made about the governance are made as they're needed. We're not setting out

any formal policies yet. We don't want to prematurely optimize the problem. So, the language is public. And about a year later, some problems are starting to show up. these are three problems that we identified with how the community was running itself at this point, 3 years on. First problem is I don't scale. I'm starting to have a hard time keeping up with the code review. I'm the

only one with push access, and it's slowing things down. Not enough is getting done. That's frustrating. Some people have been given push access informally, but they have a vague, ill-defined mandate. They're not really sure what they're supposed to do with their push access. It's a little bit unclear. So, we have a scalability problem with the code. there's also sort of at this point a strict expectation of

professionalism within the community spaces. We're here to talk about Hair and to build Hair, to work on Hair. And we've all agreed that this is good for the community to have these on-topic spaces where we approach ourselves as professionals working together for a shared goal. But because of that, it's starting to partition the community because people are developing friendships, and they're moving those friendships and those social

elements out of the Hair community, which is also causing some problems that I'll get into. And the other thing we're noticing is that at this point, I'm sure you all remember, the writing is already on the wall that radicalization is on the rise, and communities very much like ours are starting to suffer from problems that come with that. And we're thinking maybe we should be proactive about

that. So, I'm going to go over these problems in detail. First of all, how do we solve the Drew problem? Uh first, I've defined a maintainer role and nominated a few people from the community. And more importantly, we wrote a document about what it means to be a maintainer, what privileges that comes with, what responsibilities that comes with, how do you do the job of being a

Hair maintainer is established. there are some which are scoped to particular subsystem, and there are other maintainers who are responsible for the whole code base. This is also when we established the RFC and when we define what my job is at the as the BDFL. a snippet from the maintainers file in the repository, which gives you a little bit of an idea about how we organize the

maintainership. There's a link here if you've downloaded the slides where you can look at that doc. Uh but we stole this from the Linux project. They have their own maintainers file that looks very much like this, and you can see that we have some people who are responsible for specific subsystems, like Willow handles support for arm. Uh Armin handles cryptography code. And then we also have a

list of global everything. And that includes me, but also a few others. Then we've defined an RFC process. You might know RFCs from other languages like Rust that have a similar process, but ours is quite a bit different. It's optional for a start. Nobody has to write an RFC to change the language. It's a tool that people can leverage if they want to have a structured dialogue

about their proposal in order to help build consensus for a big change. Uh there's no process for these RFCs to be approved. You're just supposed to kind of read the room, and you have a discussion, and you feel out is there a consensus? Do people agree with what I'm trying to do? Is the design good? Are we ready to write the code? And if you feel like

the answer is yes, get started on it. And we also defined my role as the BDFL, and we did this in an interesting way. We did this in the form of me writing a letter to the community. which you can read. Uh there's a link here on the documentation, uh which kind of defines what is the BDFL supposed to do, which is a bit ironic. You know,

a dictator doesn't really have uh constraints, but it was really about is it useful to have somebody in this role for the community, for the health of the project? And we thought the answer is probably yes, uh because, you know, first of all, somebody has to have fiscal responsibility. We don't have an institution or a foundation associated with the project, so that falls that unfortunate responsibility falls

on me. But also things like setting the vision, organizing people, appointing people to the roles that they should be in, long-term planning, and also when the consensus process fails because there is no consensus, providing the last word on on whether or not a change is going to come in. So, that's how we address the the Drew bottleneck, right? Is we define what Drew does, we set up

an RFC process, we set up maintainership role. Second problem with the fragmented I mentioned how because we had a strict on-topic rule and a strict expectation of professionalism, socializing was discouraged. What this led to was, you know, if you you make friendships in the community and you get three people who work on Hair together in a room, they're going to talk about Hair. And when they took

their their their socializing out of the community spaces, like they were encouraged to, and into their own spaces, uh they would talk about Hair. And they would develop an insular consensus about what ought to be done with the project that they would really get put out when that insular consensus doesn't translate to a broader consensus when they bring it up before the entire community, especially if they

felt like their insular connect consensus was enough to start working on the code to achieve their goals. This led to some hurt feelings. So, we addressed this by acknowledging the social nature of our community and making a space for socialization. We liked having these spaces which were on-topic and a professional in tone where we organized the actual work, but we also established a part of the community

where you could just socialize, and the the rules were a little bit less strict. But this led uh pretty obviously into the need for a code of conduct. Um so, as you might be aware, we're existing in a in a kind of moment in society, and we wanted to both introduce social spaces, but also have expectations about what kind of conduct was appropriate in those social spaces.

Keeping it professional neatly circumvents that problem, so we kind of had to address it when we dropped that. And we also wanted to preemptively deal with the fact that a lot of people in our community uh were the kind of people who are being the targets of harassment and violence and the rising tide of the far right and radicalization. We have people who are affected by that.

It's important to protect them. So, the first thing we did was we took the maintainers, everybody who had been promoted to a maintainer, sat down and wrote an open letter uh titled All Rabbits Welcome, which you can read on our website. Uh and we basically asserted our values publicly, just said what we believed in as people and what we thought was important for our community as people.

And I will just call out two things here from the letter. One is I've mentioned here the exceptions of expressions of hate and intolerance. We carved out, I know, our answer to the paradox of tolerance, so to speak, which is we want to welcome everybody who's willing to welcome everybody, And the other thing I want to point out about this open letter we wrote, which is something

that I think a lot of open source projects can kind of miss when they talk about how they want to have a more diverse community, make people feel welcome and included. They often forget to mention that they want to invite people to be leaders. They want to be led by all of these people that we're calling out as welcome. Women, people of color, transgender people, sexual orientations.

We want them to feel welcome, and we also want them to lead us. We want to invite them into leadership roles, and we wanted to call that out here in our open letter. Second thing we did was adapt the contributor covenant to our needs and adopted as the code of conduct. One important thing that we changed about the contributor covenant is we all agreed to uh apply

the code of conduct outside of the community, which is a choice that a lot of people will disagree with. They'll say, you know, uh if people are on their best behavior in the community, then what's the big deal? This is censorship. You can't control what people do outside of your walls. And we thought, well, no, not really actually, because if somebody is a jerk who's on their

best behavior within our walls, but then goes out on their Twitter and starts posting fascist propaganda, that's not somebody we want to work with because that affects the people that we have in our community in a negative way, and we're not going to tolerate that. So, we said, our code of conduct applies outside of our community, and it governs the kind of people we choose to work

with. So, I want to talk about the outcomes of these changes, mainly about the code of conduct. It turned out when I was editing editing these slides, uh so, let me look at a couple of case studies about when we've applied this So, first of all, let's look at Joe Famous. I have anonymized all of these these case studies. Uh but Joe Famous is somebody that if

I told you his real name, you all would recognize him. He sent us an email saying that he's really excited to work with the project. And uh you know, we all know everything that Joe Famous has done. Some of his work are the shoulders we stand upon. And that's exciting to see. But also, he's uh taken a hard right turn recently, and his blog is covered in

misogyny, sexism, queer phobia, racism, all kinds of bad stuff. And we said, you know, okay, he's being polite. He's introducing us himself to our community, but we don't want to work with this guy. Uh he doesn't make our community feel safe. Uh we collectively agreed to proactively ban him from the project. And we replied to his kind email by saying as politely as possible, no thanks. And

he replied less politely than that, but we moved on. Next case study is John Doe. Now, this here is a quote from our IRC channel that illustrates the problem with John Doe. Uh he says, I'll read this aloud, is there a way to create a macro in Hare, i.e., def funken, I don't know, something like uh the equivalent feature in C. And a maintainer says, no. And

he says, why this sucks so much. Now, that's not actually against the rules to say that. Uh but it illustrates a pattern of behavior with John uh where he would set a tone in his conversations that we didn't really appreciate. And we had spoken to him informally, just, you know, person to person, or eventually moderator to community member, informally, to say like, hey man, can you tone

down your rhetoric? Let's try to be kind. Uh and eventually, his behavior doesn't change, and we sent him a formal warning after we adopted the code of conduct. We had this tool. We said, okay, I think it's time for a warning. And he says uh at this point, you know, this is not the community for me, and he moves on. And this is a bit of a

loss for us because John has contributed some good stuff to the project. Um but at the same time, uh the rhetoric and tone of the community improves in his absence, which we appreciate. And I think that leads in the long term to more people feeling safe and welcome in the community, and all of their contributions presumably outweigh John's contributions in the end. And then, let's talk about

Jane Doe. Jane has this exciting project she's working on, which controls sex toys using Hare. And she's discussing it in community spaces. She is posting uh links to her code to explain how certain features of Hare works. Look, here's an example in my own project. It's the sex toy project, right? Now, this not this is not an easy case because there's nothing wrong with this project. I

think it's really cool, personally. But we don't like sexualized language in our community spaces. And so, I speak to her privately, just person to person. I'm like, hey, I have some concerns about this. And uh this is not an a formal warning. This is just an informal chat, but from a moderator. And she says, oh yeah, you know what? You're right, and agrees. And she doesn't mention

this project in the Hare community spaces anymore. And nobody's feelings are hurt, and life moves on. She messages me later asking about mentioning this project on her Uh and I said, yeah, obviously on your personal website, not a problem. More power to you. Last one is Jimmy Place Holder Name. I have run out of ideas. So, uh this is um the red actions here are mine, uh

not Jimmy's. Um and this is just a conversation on the IRC channel. This behavior from Jimmy is not a part of a pattern. It's not normal. He's having a bad day, I guess. But this is clearly not appropriate. And Jane says to him, wow, chill. Jane is not a moderator. She's not on the code of conduct team. And this is enough. Jimmy cools off, and that's the

end of this interaction. And I mention this example in particular because it's an example of participatory governance, of the community being involved in enforcing its own values. And no moderators had to get involved in this case. Problem solved itself with Jane's help. That's it. that's all I have. I want to emphasize at the end here that uh these tools are again designed to be used as little

as possible. We saw in this interaction just before, pulling out the big hammers like the [snorts] uh RFC process, the code of conduct, is used as little as possible. And the ideal version of this community is a participatory model where everybody participates passively, actively, in building the kind of community and values and tone that they want. So, again, these are people, ultimately. It's a social system what

we've built, not just a programming language. And we acknowledge that, and the community got better because of it. That's all. Thank you. >> [applause] >> Thanks a lot for the super interesting talk and examples of community building. We have questions. I don't actually have a question. I have a big thank you for such an empowering presentation. I think this was excellent. Thank you very much. I appreciate

that. Hello. Hi. Um I loved your talk earlier. Oh, thank you. Um we were looking up to if you were what your legal status was, and we saw that you're hosted by Open Source Collective on Open Collective platform. >> That's why I liked your talk. >> [laughter] >> Um it's really, really cool to see all this governance work from um collectives. It's so important. Um I'm really

curious if you've had to do anything regarding the funding that you've got on Open Collective, and how that gets split between the people building your language. Yeah, that's a good question. Uh but honestly, the answer is that we have made very little use of that money. We only adopted a fiscal policy last year, and we've been collecting it for a while. We kind of have an ambition

to use this to audit our cryptography code, which we have implemented from scratch against the common wisdom. Uh so, we're raising money to do an audit of that. Uh and we also use that for incidental costs like renewing the domain name, the stickers you see outside with the cute Hare logo on them uh were paid for out of that budget. Uh but we are still deciding exactly

what to do with that Such a great talk. Thank you. Um I have so many questions, but I'm going to limit one to one. Um I am involved in some of the work on uh building an and evolving the W3C code of conduct. And um one of the challenges that we're having right now is um people that do work using assistive tools such as LLMs that may

be saving themselves time and energy, but in the in uh but uh is wasting other people's time and energy. And we're trying to figure out how to if that's a code of conduct thing, it should we be adding something I was wondering, do you have you thought about that in the context of your code of conduct and enforcement? Uh good question. We have not thought about that

in the context of the code of conduct, but we have talked about it. Um we're likely to adopt a policy that refuses LLM-assisted contributions in the near future. Uh but I think that we we've not actually seen any yet. We're doing that proactively. And uh the sarcastic reason why we haven't seen any of that yet is that we are not on GitHub. We use mailing lists, and

I don't think LLMs can figure that out. Uh and the non-sarcastic reason is that it's kind I don't have an answer that generalizes for all projects, but for our project, uh LLM-assisted contributions don't really make sense with the kind of software we're building. Uh it's very this is a systems programming language. It's designed to be simple. The problems we're solving are important, but not always complicated. They

don't need that much assistance to solve. Uh and all of us are kind of ethically and morally aligned against LLMs and the externalities that they introduce. And so, so far, we haven't had to deal with that, but we will be taking a proactive step soon. There's probably a lot more questions, but I need to cut you off here. Thanks again, Drew DeVault. >> [music]