Open Source Governance
Alright. Coming up next week when our guest from Noah shows up. Yeah.
Speaker 2:I do. We you know, you we we will not speak ill of Noah in this in this space.
Speaker 1:I'm also I would love to get a guest from Noah. That would that would be that would be our dream guest.
Speaker 2:So so, legit, this is one of the things that I actually was, upset about in terms of the the demise of Twitter. Weather Twitter is amazing, and it has not yet been replaced with with weather mastodon or weather blue sky. And it's, like, one of these communities that's just crazy, crazy good.
Speaker 3:You'd think with blue sky, it'd be, like, right there in the name of the
Speaker 2:there on the tin. Alright. Well, I'm you you you are not joining a Oxide and Friends on weather. Although that sounds like that's gonna be a future upset, and we're looking forward to that. But we do have Ashley Williams here.
Speaker 2:Ashley, thank you so much for joining us. And, Ashley, little bit of a of a repeat guest star here, because you were on only, I think, a couple weeks ago. Right? I mean, it feels like it was another a a a a year ago, but it was only a couple weeks ago when we were talking about this, this Rust trademark issue, and the that was, and we, in that discussion, we talked a lot about trademarks, and what it meant for an open source project, and we kept grazing on open source governance. Adam, did you did you go back and you listened to that, by the way?
Speaker 1:Yeah. I did actually this weekend.
Speaker 2:Did you? Yeah. Do you pretty interesting to relisten to it, wasn't it?
Speaker 1:Yeah. Absolutely. I mean, very impression.
Speaker 2:Very impression. Yeah. Because I think, Ashley, you in particular were hitting on some governance issues. And, and Adam Jacob was there and describing how much he would love to just, like, have the like like weather Twitter. Like, let's nerd out on open source governance.
Speaker 2:And we we kinda grazed these issues, but you made a bunch of really good points about why the the the trademark issue we were discussing was actually reflecting some deeper governance issues. And just for for context for broader folks, the reason we are here now is we there there was another, blow up for a lack of a better euphemism, where the, over the weekend, a, Roskopf made a pretty serious mistake, and they they they demoted a keynote from a speaker due to reasons, and, that speaker rightfully pulled out of the conference and, then wrote actually a great blog post explaining, here is why I am not gonna be presenting at RussConf. That caused a bunch, then other folks, folks in the core team, they began to describe, here are some of the problems we see with Rust governance.
Speaker 3:Well, I may jump in just real quickly, Brian, because the core team doesn't exist anymore. So we should probably call it what they call it, which is gonna be a phone topic probably, which is leadership chat. Which if it sounds like a group text, like, that it is.
Speaker 2:It does sound like group text. I feel like if you've every time you see leadership chat, you substitute group text. I feel that, like, that's kinda how I hear it. So, yeah, I agree. So the the but a member of the the the leadership of Rust stepped away and wrote a blog entry explaining why.
Speaker 2:And there was a lot of, and then a lot of bad takes on it. You know, it's just absolutely loaded with bad takes. So we actually don't wanna dissect all of that in part because the Ross Comp folks have acknowledged that this was wrong. This is a mistake. And they they erred when they they pulled this keynote, what it was a mistake to pull it, and they were they sorely regret the mistake, at least according to them.
Speaker 2:And I think we don't wanna talk about the the the necessarily the mechanics of that, although that that probably merits some discussion. I think what we wanna get into is how did did a community get here? How did a leadership team get here? How did an open source project get here? And in particular, I wanna talk about the issues that are not just unique to Rust.
Speaker 2:Because, actually, I'm sure one of the things that that you were very frustrated by is, everyone using this as an opportunity to be sanctimonious about their own language or community or system where it's like, well, we would we never have these problems over here in this community.
Speaker 1:It's, like, well,
Speaker 2:come on. There is a lot here that is is endemic, and that's kinda what I wanna hit on. Actually, when you were on here, again, a couple weeks ago, I think you had a bunch of really good openers. And just by by way of of introducing you, someone who's been in in a bunch of different communities, but in particular, you and I both share history in the node community and in the Rust community, which I think gives us a lot of perspective. You were you were instrumental, in setting up the Rust Foundation.
Speaker 2:So you've you've, been around the block on this one for sure. So first of all, welcome. Thanks for thanks for coming with it coming on on Send Friends to talk about this.
Speaker 3:Thanks for having me. I wish I had reviewed the things that I said in the trademark conversation like y'all did ahead of this, that I I haven't. So I'll have to alter leave it to you to remind me the things that I said. But yeah. I don't know.
Speaker 3:It's it's been So I left Rust governance mid last year. I don't know. It's been interesting to reflect on how governance in Rust changed over my tenure there, and then how it's changed since, and then, like, comparing that to, like, my experiences in governance in Node and even kind of, like, tangentially in the Ruby communities. But, yeah, I guess the first thing I would definitely say is, like, I only think the only thing that I really think is categorically different between a lot of those things is, like, the passage of time. But, yeah, I I it's, it's it's interesting to see, and I do think how folks are reacting to these types of things have a lot to do with, like, the different expectations that folks have these days of open source and open source governance.
Speaker 3:Which is funny because if you, like, look 5 years ago, some of these, like, requirements, like, were unheard of and in many ways, like, unspeakable.
Speaker 2:Elaborate on that. What kind of requirements? How have that how has it changed in the last 5 years?
Speaker 3:Well, I mean, I think it's probably worth noting that, like, the suggestion of having a code of conduct was, like, inflammatory. And, I mean, regardless of how you feel about codes of conduct, I have my own complicated opinions about them. But, like, I think the requirements for transparency, the requirements for plurality, like, the fact that the one to many communication style has kind of, like, been amplified, and then what is tolerable on Twitter versus not has also changed.
Speaker 2:In what direction has it changed by the way? I'm not sure. It's turning Well,
Speaker 3:so Twitter to the bill. Somebody who was, like, a little baby open source governance person in, like, 2017, like, right when tech was, like, oh, maybe these gamergators have a good idea of what's going on. And, like, cancel culture was, like, in full swing, honestly, on both sides. And, like, I think a lot of things have shifted from that, like, the way things often shift, like, as a reaction to an extreme. But, I mean, I think I think we've put a lot of requirements on governance when a lot of the original open source governance was happy to be this one brilliant genius guy in his garage and we just listened to him.
Speaker 3:Yeah. And now now we have, like, multi, like, $1,000,000 organizations with massive companies sponsoring individuals who sit in a room and have 8 different levels of documentation. Like, it's it's a pretty radical change.
Speaker 2:Yeah. So let's talk about that. Because so what you're referring to, of course, is the BDFL model, the benevolent dictator for life model, which even that term is sounding like increasingly dated. I I I don't know. And right It's not
Speaker 3:that long ago.
Speaker 2:It's not that long ago. And we and I think that part of the reason that sounds dated is because I think that for a long time, people were looking to I mean, I I think it's fair to say that Linux popularized the idea of the BDFL. It'd be interesting to know if it's even coined in Linux, but certainly, it was the canonical BDFL. You've got this, eponymous, system that, clearly the Torvalds is the the dictator for life, of Linux. But I I don't know.
Speaker 2:Adam, it might maybe this is we're misreading history here, but it feels like when the the when there was some hot water well deserved hot water, about how people are being treated in Linux. And people were saying, like, look, I'm no longer contributing to Linux because I don't wanna deal with these kind of flame wars on the mailing list. And people begin to realize, like, maybe this model, like, is not is not perfect.
Speaker 1:Yeah. Well, it it I mean, the FL is sort of tongue in cheek for life, but there is a real generational problem built into it, where so it's not going to these projects. And I think I heard BDFL even around, like, Larry Wall in Pearl and Van Rossum on Python. So even before, I I I've heard that associated with with Linux, but maybe I'll get the time timing run. But, you know, the like, how do you how how do you keep someone's attention literally for their entire life without them wanting to move on to the next thing?
Speaker 1:This whole idea of, you know, how you pass the torch is pretty tricky.
Speaker 2:It is, Richard. That's a very good point about it being that it you do have this kind of generational problem built into the for life business. In that, like, how do how do you assure that a system is going to shift as it needs to with time and shifting mores when you've actually already kind of enshrined. You're you're you know, it kinda reminds me
Speaker 1:of You
Speaker 3:basically only say you just say succession. Sorry.
Speaker 2:Okay. Alright. Now okay. We do
Speaker 1:we definitely walking you there. Right?
Speaker 2:Okay. We we we finally got it out there. So, this past weekend was the the season finale and series finale to Succession. Adam, we all know that you, you you like to watch your television 20 years after it comes out. So we know that this is we this is really just speaking to Adam Leventhal circa 2043.
Speaker 2:But for the for the rest of us, we actually watched the Succession finale, over the weekend. Terrific finale. And I do feel that, actually, I mean, succession does feel like it's not unrelated, because it's succession is and I think when we talk about, like, open source governance, we are it is at some level about power or perception of power. And, you know, why what makes people crave it? What makes people fight for it?
Speaker 2:What and I think it's power in contrast to to leadership, which I think is is because when you have a, a a a BDFL project, you know, you have and on the one hand, you've solved some problems, I guess, in that, like, well, governance, I guess, is solved. But you've also created now the project is actually a person, almost by definition. And it's gonna actually follow the whims of that person, which is
Speaker 1:A great problem. Because because dictators are not famed leaders. They're they're famed strongmen or or they're straight famed for the power. So, you know, built into it is not this notion of rallying the community, but rather, you know, leading by fiat, not not by, you know, by true leadership.
Speaker 2:Adam, that's totally true. And I think it it kinda reminds me of Google's like, oh, our model is, like, don't be evil, where it was meant as, like, oh, this is meant to be, like, ironic, and then it all of a sudden became, like, the bar. Like, no. No. No.
Speaker 2:We're not gonna be evil. You know? Sorry. Well, no. We're gonna be bad, but not evil.
Speaker 2:We're gonna be shady.
Speaker 1:Right after that line. Yeah.
Speaker 2:Right after that line. And you're like, you know, I think you meant that as a joke. And I feel like BDFL too is, like, BDFL, like, it's meant to be tongue in cheek, I think. Right? Isn't it kind of, like, winking at the idea of, like, no.
Speaker 2:Of course, like, dictators for life. That's obviously bad. But this is a benevolent dictator for life. So it's and but we we kind of drive past the fact that, like, wait a minute. Dictator.
Speaker 2:It's like this is bad. This is fundamentally not a great structure.
Speaker 3:So So I think maybe to, like, kind of pop the stack a little bit. I think one of the things that's interesting about the topic that we wanna talk about today is I think the original way you phrased it is, like, who who governs open source? And I feel like already between, like, you and Adam, there's been some, like, really interesting questions here. But I I don't think there's consensus on, 1, if open source needs governance, and then 2, if open source needs governance, what that governance is. And I think a lot of that has to do with kind of what I see as, like, the life cycle of open source projects.
Speaker 3:Because I think what governance is and needs to be, like, changes really dramatically over the life cycle of a project. And I don't know. Humans are bad at transition. But, like, succession between those different stages of governance I think can be really really complicated and I think that's certainly something that's identifiable in this situation with Rust, which is, like, Rust has existed for a very, very long time, and it has changed really dramatically over the course of that time. We are in, like, a new phase, and everybody involved is reacting to that, in positive and negative ways.
Speaker 2:Actually, elaborate on that. What what are some of those stages? And and, you know, where maybe maybe we can talk about maybe some certain projects that are at at different stages in the kind of the life cycle.
Speaker 3:Yeah. So, I mean, since we were talking about BDFLs, it's probably worth mentioning. I'm sure it's been mentioned on the show before that, like, in theory, you could describe Russ as having started kind of vaguely in a BDFL model because it was somebody's kind of side research project, that became their work, at Mozilla. And then as things grew and changed, like, different groups of people, were put together, to try and help organize it. And I had to do with, like, the growth of popularity, the growth of usage of the project.
Speaker 3:But, like, most open source projects don't start with the idea that, you know, eventually the US government is gonna endorse people using it.
Speaker 2:Yeah. Well, right. Yeah. I mean, well and also this is one of those where if you were to get in a time machine and you were to tell Graden, like, this is what happens to Rust, you run the risk of, like, really changing the future. Right?
Speaker 2:Because I just you would change people's behavior in a way that would ultimately make it potentially not successful.
Speaker 3:Yeah. Absolutely. I mean, I think and I I think you see this in companies and like, I don't know. There there's a lot of reasons why metaphors about like, companies and products to open source, like, people don't like it. I think the economics are actually, like, kind of similar, which have a lot to do with this.
Speaker 3:But, like, yeah. A failure to adapt, like, when you go from, like, the 0 to 1, the 1 to 10, the 10 to 100, kills most things.
Speaker 2:And and I think also this idea that, like, not every open source project is gonna do is gonna gonna go on that trajectory, or should. Right? I mean, it's like the an open source project can stay small. And, I mean, I'm speaking for many many of the ones that we are involved in, Adam.
Speaker 1:Right.
Speaker 2:Where I mean, it's stuff that's like that I mean, and some stuff, like, no one else is using. Fine. That's easy. Some stuff, like, a small number of people are using, and it kinda stays easy. And then it's it's I mean, are we gonna ever have, you know, a drop shot foundation, Adam?
Speaker 2:I mean, that feels I don't know. Feels feels unlikely.
Speaker 1:It feels unlikely. The drop shot being the the web framework that Dave Pacheco and I, built early days at Oxide. And this gets to Ashley's question, do we do we need governance? And certainly for lots and lots and lots of projects, even successful projects, like, you don't really need governance. So I think it's an interesting question.
Speaker 1:When at what point does that does that necessity become the mother of invention? Right? At what point does that governance, you know, become something that is is worse than its absence?
Speaker 2:Yeah. What is the Rubicon that our project process where it's like, okay. We actually need and I mean, this obviously happens in companies too where it's like we and and, you know, we talk about Dunbar's number a lot as kind of being a stylized where you really need to kind of start thinking about the things differently. But actually, do you have a rubric for where we start thinking about, and and as Colin says in the track, small open source projects can also have huge drama. That is absolutely true in this definitely.
Speaker 2:You can have I feel like the number of people required to have an open source desktop might not even be 2. You might even be able to do it with a a single person may be able to actually a one person project, may Totally.
Speaker 1:I mean, I look at lots of issues I filed on my own projects and thought, what is this knucklehead thinking from 6 months ago?
Speaker 2:Did you did you ban past Adam from your project? And actually, past Adam resigned. Past Adam wrote a blog entry resigning, so forget it. Forget that guy.
Speaker 1:Myself. Right?
Speaker 3:But it
Speaker 2:just does not do for many people. Yeah. Actually, but do you have a rubric?
Speaker 3:This is alright. I mean, one, no, I don't have a rubric, but are you, like, calling out the former middle school science teacher, for so many rubrics? I mean, like, I think of governance as abstraction, like, fundamentally, and I do love being, like, really reductionist and, like, calling everything an abstraction. So that's, like, a character flaw. But, like, you should build it when you're able to, like, feel and identify the pain of its absence, is kind of how I think about it.
Speaker 3:And so, I don't know, someone said this to me when I was helping set up the Rose Foundation, but it was, like, it's always better to have a foundation too late than too early. And
Speaker 2:Yeah.
Speaker 3:I think I agree that I Adam has posted something in the chat and I'm, like, very interested in him, like, expanding on it. Because it sounds like it might be in disagreement with what I'm saying, but I'm not entirely sure what it means. But But
Speaker 4:I only have 8 minutes. And then I gotta
Speaker 3:go. It?
Speaker 4:I only have 8 minutes.
Speaker 3:Oh my gosh. Well, then hurry up. I'll stop learning.
Speaker 4:I'll do
Speaker 3:what you mean. So
Speaker 4:I think I think the hardest thing about adding governance in open source projects is the lack of explicit power in general. And so there is this explicit there's an implicit thing that's like, okay, whoever started the project gets to do what they want. And that can be fine, like, right? If there's 2 of us, fine, right? Like I started I get I get what I I get my way, you know?
Speaker 4:But I think the sooner you can make that explicit, the better off you are because now you can use that explicitness to bootstrap your way into healthier forms of governance. Right? So as you grow, there's there are rules. There is a structure. There there is a mechanism.
Speaker 4:It might be this most trivial of mechanisms. Right? It might just be whatever Ashley says goes goes. Work done, you know? And at some point, it needs to evolve to, like, a more structured kind of governance.
Speaker 4:But I think we've seen this failure in a lot of different modes where you can get to a really frickin' big community little syndicates forming that, like, know how to manipulate that structure and then and then then then they fight.
Speaker 2:Yeah. It's this is really interesting, Adam. And you're it's hacking into what I think it's kinda Ashley's rubric of when you can identify the pain of its absence. And, Adam, what you're talking about when you've got, you know, the this kind of whispering happening and you've got kind of lieutenants that are shadowy, that are I mean Totally. It feels like okay.
Speaker 2:So we're beyond the point where we need because you've got people who are putatively involved in the project, who are actually don't know what's going on because there is not transparency. And that feels like, yeah, that's kind of beyond the point where you need governance somehow.
Speaker 4:And and to the point that you a foundation is better later, I think that's really real too. So, like, I I don't think it's it means that you should have a foundation sooner. I think it means that, like, you know, whatever the structure is, it just needs to be explicit and not implicit. And, like, I think you can see this in Rust right now. I think you can see it in Nicks right now.
Speaker 4:I think you can see it in a lot of communities in the past where, like, those implicit power structures and people's ability to just get what they want because they under either understand it or have a posse or they're the loudest on Twitter or whatever. Like, there needs to be a mechanism that allows that allows for people to resolve their conflict. And ultimately, like, without an explicit way of resolving conflict, then what do we do? You know? Like, it's gonna get resolved one way or the other, you know?
Speaker 3:I have a lot to say about this. And I guess I've one of the things I wanna jump in on with this topic between implicit and explicit is, like, the way we're talking about it now is, like, we kind of, like, a evolutionary progression, which I do agree with, which is, like, when in the beginning, everything is implicit. And then there's kind of this perception that, like, you know, the goal is to transition it to explicit. I I would and this is potentially a bit on the nose, but, like, I would say and I have said very publicly on Twitter that I think one of the biggest problems in Rust right now is that the power modes in Rust are all incredibly implicit,
Speaker 5:which is
Speaker 2:incredibly implicit.
Speaker 3:Pleasing because we have a lot of documentation and a lot of kind of laughing about about a lot of this, like, kind of very distributed, structured
Speaker 4:But nobody's willing to actually commit to leadership. They're only willing to be like, there's a council.
Speaker 3:Well, so I think the next thing that I would say, and this is, like, perhaps some of where things get really dicey and I think is part of, like, the failure modes of this current situation, is that the transition between implicit power and explicit power is very difficult, and it's very as as some personally who spend a lot of time advocating for creating more explicit power structures with accountability structures, like, in the project. Like, you are not a favored person when you are doing that.
Speaker 4:This is why it's better to do it when there's 2 of you.
Speaker 3:Yeah. And it's Yeah. It is. Easy to turn that person into a villain. Yeah.
Speaker 3:And
Speaker 4:I made a I made a random comment on Twitter that if that there's an executive that's needed and the reason is that you can be a villain. Like, not every CEO is beloved because sometimes they have to do things that people don't like. And, like, the what's good about that is you can fire them. You know? Like Yep.
Speaker 4:Like, and also what's good about that is they can do things you don't like, which may be necessary in order to actually write the metaphorical ship.
Speaker 2:I would also say what's good about that is that that, Adam, is so great to thank you so much for coming by briefly. The but the, I also think that the presence of that and the presence of that accountability acts as a check on your own actions, which I think is extremely important that you when you have to put your name to something, you I mean, this is SOX compliance has been huge. Right? CEOs having to put their actual, like, name to their financial statements and certifying it. It really changed the way people actually process the stuff internally in companies.
Speaker 2:Because when you have to put your name to something, and you have to take accountability for it, responsibility for it, it will change the way that that that you that you act in a positive way. Because you begin to think about, what are the ramifications of this? How could this be misinterpreted? How could this be interpreted in a different way? And it will it will force a a good leadership will will seek out this kind of moderate middle.
Speaker 2:And, you know, I know I I think Jeremy Sawler's here. Jeremy had a great tweet over the weekend where, you know, he was saying, like, look. The the problem that I see it here is the the lack of transparency is a huge problem. We've been calling it implicit. I would say that actually right now, or I'd say up until now, because I think I I I'm optimistic that things are gonna change with Rust.
Speaker 2:I think it has been worse than implicit. I think it's been secret. And secrets are bad news. I I really do not like secrets. I'm I I I'm I'm an oversharer probably.
Speaker 2:Adam, you're probably like, hey. You know what? You could use a a little more secrets, by the way.
Speaker 3:You you
Speaker 2:don't need to maybe you could,
Speaker 1:Not not to expand on the taxonomy too much, but it's it's not just, you know, this this secret. It's this implicit secret where, I I think, like, you know, things get signed by, you know, groups and groups. We don't even know who the the folks are behind these groups. It gives a lot of anonymity and a lot of, you know, cover to lousy decisions, I think in the name of, you know, protecting one's privacy and so forth. Well, I think Yeah.
Speaker 1:Please.
Speaker 3:Well, just on the on the two reasons I think why why people do this, and this is not necessarily an excuse, but I think it's at least a physics of the situation, is, 1, it's, like, worth noting, and I know it's been explicitly, like, considered as part of this situation. Like, when gamergate went down in the tech sphere from, like, 2015 to, like, 2019 or whatever, like, raving hordes of just complete bigots were, like, absolutely ruining people's lives and, like, stalking them. And, like, those people are at least aware of the people that were targeted by those things. And so they do wanna make sure that, like, that doesn't happen. I think that we are in an explicitly different situation today, but, like, that is something that people are worried about and, like, it does ruin people's lives, like, for sure.
Speaker 3:I think the other one which is, like, more interesting is that when we talk about transparency, it's important for us to talk about transparency at scale and what the economics of that are, and also try and recognize the levels of scarcity in which a lot of these governance bodies are operating in. Not an excuse, but being fully transparent takes a lot of work. Like, doing it well. Not just like, oh, here's, like, 200 pages of minutes, like, have at it. Though I don't know.
Speaker 3:Maybe AI solves that for us. But yeah. Like like, it's hard and this is where there's a transition that happens in open source governance that people get real spicy about. And I don't think people have resolved this at all. I have my own personal opinions, but it's the idea that you need to have people working in governance that aren't the meritocratic, technical genius authors that you started with.
Speaker 3:And then how those people can remain powerful and, like, respected, when they're making these tough calls, when people are, like, oh, well, you aren't, like, really, like, contributing. It's it's a big problem. It's, like, a big and that's where, like, I've seen a lot of this stuff fall apart. It's where Node fell apart. I think it's where Rust is at the moment.
Speaker 2:And in terms of where the these contributions to the community, namely contributions to the governance, are not viewed as as technical contribute. They're not they're not viewed on on the same kind of level as technical contributions, and they are indeed they're they're viewed as kind of regrettable. That that not an important part of the of the community.
Speaker 3:They're often seen as people trying to grab power.
Speaker 1:Right.
Speaker 5:Yeah. I I have to agree almost a 100% with Ashley here and everything she's said in the past 8 minutes that I've been here. There is there are a few things that have struck me about the Rust project in general. And I haven't been on the inside like some of you have. Steve has been inside.
Speaker 5:Ashley has been inside.
Speaker 2:Adam and I are in your category, Jeremy. Yeah.
Speaker 5:Exactly. So, from the outside looking in, it it appears to me, like, there are a lot of people who could lay a claim to having official, you know, vested power from the Rust project. And that is a serious issue. When you look at the leadership chat that's been built, it includes all of the people on the core team, which makes sense. It's a small team.
Speaker 5:It includes basically all the people outside of the core team on all the other teams. It it's, it it it Well, I would
Speaker 3:estimate it
Speaker 5:includes several dozen people.
Speaker 3:I believe it's 17. Yeah. But just to be clear, the it's not every member of every team.
Speaker 5:It's the the co leaders of each team?
Speaker 3:Yeah. It's the leads, which and you can have multiple leads on a team regardless of the team size.
Speaker 5:But Right. Yeah. Yeah. So so and there are multiple leaders on several of the teams. It it it is an astounding amount of people to come to any consensus even if you had a mechanism by which to come to consensus.
Speaker 5:And, there is no such mechanism. And I believe that I believe very strongly that projects need to limit the growth of of who is in positions of power until they have a a well established mechanism by which to do that, and that people who are placed in positions of power need to be those kinds of people who are willing to put themselves on the line anytime a decision is made. And that has not been the case. We basically, what what has happened from my perspective, and please correct me if I'm wrong, people who contribute heavily to Rust can then ask to be part of the the, groups, the core group, the library group. And because of their contributions to the code, may be given a spot on those teams, Not because they're a good leader, not because they're good at managing things, but just because they they are good contributors.
Speaker 5:And that is definitely not a way to build, a set of publicly facing individuals, because good coders are not good managers necessarily. We're good at managing machines, not necessarily good at managing people. And then what ends up happening is that those kinds of decisions that are made are treating people as though they're machines. You know, telling a person, oh well, your talk wasn't exactly what we expected, so we're going to downgrade it from a keynote to just a regular talk. It's something you could easily do to a computer, but not to a to a to a person.
Speaker 3:I wanna jump in just briefly, because I I do see some folks bristling in the chat, and I don't think it's, like, entirely Is there a bristle? And I'll I'll I'll I'll respond to what Jeremy said with this, which, we'll see is I I would go so far as to say that, like, how governance works in Rust is kind of, like, worse than what you said, but potentially not, like, for the reasons that you think. So Mhmm. It is true that for many teams, and in particular, like, technical teams, which I'm I'm already, like, getting myself into a hole there probably. Like, you are largely, like, invited to be part of the contributor group, part of the team, part of leadership based on your contributions.
Speaker 3:I do think it's reductionist to say that it's strictly based on your technical contributions. There's folks who have, like, invested, like, their work, like, exclusively in documentation or, like, exclusively in error messages, which, like, you can is maybe formally code, but, like, ultimately, like, a lot more to do with user experience. And there's lots of people who have gained, like, leadership roles as a result of not technical communications or or contributions. And I I think folks the the path is much harder, I think, for that and, like, I think you see less of it, But it definitely exists in Rust. I think the harder thing is, like, how much power people think those people should have.
Speaker 3:Like, it and this is spicy, and then I'll I'll step back, and I would love to have Florian chat about this too. I know he's in the audience. It's worth noting that the current state of governance is the result of what I, as a joke at least, but I don't know how much of a joke it is, called it a coup, like, 2 years ago almost at this point. But, like, this wasn't the state. And this isn't to say that, like, the state of Rust before then was good.
Speaker 3:I'd I've actually explicitly said many times that it was bad. But one of the reasons it's, like, uniquely bad right now is because a lot of people decided that there wasn't enough representation from technical contributors in the governance. And for lack of, like, time, I'm just gonna say, like, kinda tore it all down. And then they're like, we'll build something new. And then, like, 2 years later, it's like, dang.
Speaker 3:Building something new is, like, really hard.
Speaker 2:Well, I I think it does get to to Jeremy's point for me because I think you're making a a very good point and one that is obviously time tested that, technical contributions and human interactions, you can be good at 1 and not necessarily good at the other. And we often do, have a lot of folks who are in positions of leadership because of their technical contributions. And then they are are, they don't have the ability to really navigate conflict, which ultimately is what we're talking about here is right now beginning conflict. We talked about, you know, when you you need governance when you're navigating conflict. One thing I would just, like, put in a a just a quick, pitch for, so Rachel Stevens gave a talk at Monktoberfest this past year on introspection gaps.
Speaker 2:I don't I don't know if you have you seen this? This is a
Speaker 1:No. I haven't. Oh, okay. In the chat. Hi, Rachel.
Speaker 2:I, this talk is terrific, and I've actually I it's one that really rewards relistening, about and I I'm actually I've been sending out a bunch of links to this talk. I'm gonna send out a bunch more links to this talk, to folks that are kind of wondering how to proceed, especially when you when you screw up or when you're trying to understand how to navigate conflict. And, you know, one of the things that that Rachel talks about there that I go back to again and again and again is that so much, bad behavior from ourselves, speaking for myself personally, but I see it in others too, bad behavior comes from fear and getting to that fear. What are you afraid of? And asking that question directly.
Speaker 2:And, Rachel, thank you very much for that. Again, terrific talk, and really highly, highly, highly recommend it. It's a question that I have asked of myself a bunch. I've I've asked of others too. And I think when we when so when there is conflict, asking people what are you afraid of?
Speaker 2:You can often get to, because I I and I feel that you can you can get to away from from what is this kind of Machiavellian maneuvering and get to what are we actually trying to do here, and what is the outcome that you're trying to prevent or trying to move towards and why. And getting people to kinda talk frankly about that, I think, is is really, really important. So, Jeremy, just on that point, I because I I think that this is a talk that a technologist it it can resonate with a technologist. They can understand and begin to kind of put some words to some of these things. Because I think when we when we don't do that, and we you know, Adam, you're fond of the the the the the squishy humanness of it all, and we like to we we wanna disregard the squishy humanness of it all, and then we end up, especially with these implicit structures, where we end up doing things that aren't that really have, pretty bad consequences, and, intentionally or no.
Speaker 3:I think one thing I wanna add to that, and I guess it's what I was a little concerned about with what Jeremy said, is like, I don't think, like, the same way I don't think this is unique to Rust. I don't think it's unique to tech.
Speaker 2:Totally. Yeah.
Speaker 3:And so, like, I I hear you on, like, oh, you it's easier to imagine someone treating someone, like, really transactionally when you think about, like, how they engage with a computer. But I don't know. There's also a whole bunch of, like, coders that do distributed systems and, like, I don't know. Computers can be super complicated too.
Speaker 2:Well, although I do actually, I thought you are right, but I do feel in other domains. In other domain, in in any domain, you have this this challenge that someone who is good at that craft will be ultimately be managing people, and they won't necessarily and because I was on the board of preschool for many years, and they had, like, similar but totally opposite problems. And, Ashley, I know you were being a teacher that you probably saw a bunch of this where they are being a great teacher also does not make you a great manager of people, but the the failure modes are totally different. And the, so I I do think that there's something that is a common theme across all domains, but I think that we I I do agree with Jeremy's point that you do have this idea that in our domain, one of the failure modes is frankly a lack of of empathy and thinking strictly mechanically.
Speaker 5:I I say I don't know of any open source communities where there hasn't been drama. So to to add to the point you just made that there is no perfect governance structure, and even trying to imagine it is not gonna come up with with it. But there are places that I felt much more comfortable. I think Elixir actually when I was dealing with Elixir, it was a much maybe it's a smaller community, I don't know what it was, but it felt much easier to deal with and, more disconnected from the sort of things that have happened recently to Rust.
Speaker 3:So Yeah. Go ahead, mister Suraj. I have, like, 2 responses, but I feel like there's kind of, like, 22 things on the table right now. So the first thing I wanna do is I get why we say, like, oh my god. There's so much drama in Rust.
Speaker 3:But I also think that it's reductionist and Yeah.
Speaker 2:I agree with that.
Speaker 3:Instructive.
Speaker 2:Yeah.
Speaker 3:Here's the thing. When you're were and, like, I have had people tell me this a bunch, and it doesn't really comfort me that much. But, like, when you're working on something that freaking matters, like, stuff happens. And, like, the more it matters, like, the more people care, like, the more stuff. And so, like, it's worth noting that, like and maybe I'm in the startup world and I've been completely corrupted now, but we're like, we're it's at the hockey stick, like, inflection point as far as growth goes.
Speaker 3:Like, it's literally, like, in a rocket taking off right now as far as, like, popularity. So the stuff is just really freaking hard. And if nothing was going wrong publicly, I'd be worried because privately. I'm thinking yeah. Exactly.
Speaker 3:So, So, I mean, the fact that some of this has happened publicly is at least, like, it is a testament to some amount of transparency. That's true. I still think all of it could have happened extremely differently, but it is what it is, and hindsight's 2020.
Speaker 5:I mean, I can imagine if every if every person had to sign an NDA to to do anything with the Rust Conference, then we never would have heard any of this.
Speaker 3:Yeah. And NDAs have absolutely been weaponized inside the Rust project before, and it's it's gross, and it really sucks.
Speaker 5:Yeah. We know all about that in the hardware world.
Speaker 3:Amazing. So, like, there there are worst case scenarios here. I do think that there's, like, really interesting structures to look to. I'll admit that I've kinda, like, not been exploring the open source side of things for a while, but, like, I mean, there's a lot of, like, activist cultures that I think are really interesting that have, like, cool governance structures. I think at least one of the things I'm, like, uniquely kind of excited about, and I don't know if you would strictly call it, governance structure, but since conflict resolution and governance is something we've been mushing together in this, I would say, I think a lot of, like, restorative justice practices are really interesting, and I think would probably really benefit stuff like open source, because I think one of the biggest struggles that people have with open source is accountability and how it relates to personal sacrifice.
Speaker 3:So if you think about how an open source govern like, open source project grows, like, it's often a hobby. It's also it's often the source of, like, all your friends. Like, it's, like, one of your primary, like, like, social side gigs. And, like, when we hold people accountable, especially the way we were kind of taught to after gamer gate with these codes of conduct where it's just like 0 tolerance. Like, if you are gonna be held accountable, like, a lot of us think that the way that you're supposed to hold people accountable is to just completely socially isolate them.
Speaker 3:That's terrifying. It sucks for the people who have to do the isolating, and it sucks for the people who have to be isolated. It's, like, really high stakes. And so
Speaker 5:why these back channels get built, to to try and hide, things that may be that may cause an explosion. People do things in DMs when they would have used public channels. People people talk 1 on 1 with people and cancel talks when when they would have done it, publicly. It's and I don't think any different governance structure will change that if the people are the same. If the people are the same, they're still gonna talk to each other through DMs.
Speaker 5:They're still gonna make decisions that way. Even even you layer on a governance structure, there's no guarantee that that it's going to actually be followed.
Speaker 3:Well, the the thing I was gonna say addresses that, which is I think if we had ways that didn't feel like jumping off a cliff to manage conflict and accountability Yeah. It would be a lot easier to make mistakes and to do so publicly and to be able to own up to it. And I think that that's something, like, Brian mentioned, like, Russ has learned a lot from previous projects and adopted those things and grown. Like, I think, like, many things, like, I think there's been an overcorrection. And that, like, a way that Rust deals with a lot of its problems is to disappear people, which is, like, super messed up.
Speaker 3:And, like, that again, it doesn't just affect the people who get disappeared. It affects everybody who knows that person got disappeared. It's like, well, I don't wanna be disappeared. Like, these are all my friends. Like, what I'm gonna what do I do?
Speaker 3:And so I do think it really starts with trying to think about, like, how we punish people and how we how we react when something goes wrong and how we can how we are able to, like, restore the situation and bring it back together without resulting in, like, trying to punish people and socially isolate them. I think that's something that if the Rust project could do, it would help it a lot. We could catch problems a lot earlier before they become disasters. And, in many ways, we'd be we'd we'd be able to try and, like, you know, in ways, save some people. And by save, I kinda mean, like, retain them, because we'd lose lots of people.
Speaker 3:And I think that that's really sad. Now the same problem comes back to it though, which is that, like, when open source operates in a scarcity mode, like restorative justice, if anyone here has ever participated in a restorative justice process, is so time consuming. Like, doing the right thing takes so long. And when you're operating from a place of there's so many things to do and not enough people to do them, I'm so stressed out. What do I do?
Speaker 3:It becomes really easy to just be like, make these problems go away. And that's that's just really tough. And, like, I know I'm the the leftist here who's saying it's capitalism's fault, and it's, like, the most basic cringey thing to say ever. But, like, when we realized that, like, this massive influx of money into open source has not been an influx into solving, like, these types of problems, Like, I think it's no surprise that, like, they are the ones that tend to dominate these things. Like, if we paid if I gave a talk at Microsoft Research once about supply chain security, like, they invited me to talk about, like, Russ and supply chain security.
Speaker 3:And, like, in a classic way, I was like, yeah, I'll give that talk. And, like, didn't talk about supply chain security, at least not in, like, the classic sense. I was like, the humans of open source are the supply chain security crisis, that we have right now.
Speaker 2:We we are all downloading software off the Internet running it. Yeah.
Speaker 3:And I think
Speaker 4:like that at all.
Speaker 3:So I spent a lot of time talking about that, but, like, I think it's true. But, like, there's no startups for that. No one's, like, throwing a ton of money at that. But, like, I I think that that's genuinely what needs to happen. Like, someone I think it was Brian said earlier, like, a lot of this stuff, this bad stuff comes from fear.
Speaker 3:Yeah. I think a lot of people are really, really afraid of doing something wrong and having the Internet attack them.
Speaker 5:Yeah. Well, I would make the point
Speaker 3:that it's because
Speaker 6:that's what's happening.
Speaker 5:Perhaps the leadership of Rust should be limited to those people who are okay being publicly attacked. And the rest can always lay behind the leadership's decisions. Like, oh, well, that was that was a decision of, you know, these 5 people who are who are tasked with taking the brunt. And it's just, you
Speaker 3:would Here's the thing. When that happens, like, that's kind of what was happening with the original Rust core team. And, like, those people took the accountability. And then, like, no one really liked them that much anymore, and since they got rid of them.
Speaker 5:Yeah. I know. I know. All the people I used to know are are out. It's it's crazy.
Speaker 5:And JT just left. It's I don't know anyone there anymore, personally, at least.
Speaker 2:Well, I I think that this is the challenge because, like, leadership is really challenging. We've kind of we've been using leadership and power interchangeably, which I think is really unfortunate because I I think that, when you phrase it as leadership, which is what it should be, what it is, it is a much more accurate expression about what you what you can and can't do. I mean, in terms of the the actual, like, power power is kind of limited. And, unfortunately, it's limited to the kind of actions that we saw that kicked us off where it's like, yeah, you can figure out, you know, what the program is for a conference. Like, that is actual, like, decision making power.
Speaker 2:But there is in most projects, in most entities, it's there there's much more leadership than there is power. It's much more getting people to do to go in a direction that you think is the right direction. And I I feel that we, Jeremy, I agree with you that we we need that need that leadership and we need that leadership to be accountable, and it's not fun. It's hard. And I think, actually, to your point of, like, yeah, it's to the point where, like, it's such a downer to have people doing this that they get thrown out because, you know, the the the project needs to want that leadership, and I think that that's that's part of so, actually, actually, let me ask you a question.
Speaker 2:The you know, one of the things that's kind of interesting about Rust is that and I think it's part of its success as well, is the fact that Graydon is not really involved. And the fact that there is no, that there's no kind of authority single authority to appeal to, is that a bug or a feature? I mean, it gets gets into the back into the BDF question a little bit, but, I mean, it it it
Speaker 3:does come your expectations are. What did the doc say? No. Sorry. That's a Semver joke.
Speaker 3:A little Semver humor? What was that?
Speaker 2:A little Semver humor?
Speaker 3:Yeah. The tough crowd. I also see that Rachel has her hand up and so Oh,
Speaker 2:yeah. Did her do it? Yeah. We
Speaker 1:have Rachel
Speaker 3:say something. But I guess the thing that I would just quickly say is I think, like, many things, like, it really depends on your perspective. Like, in the grand scheme of things, I don't think that an individual person like, I don't think it would be tolerated.
Speaker 1:Yeah. That's right.
Speaker 3:And so I think that you have to do something different. Weirdly, the economics of it being a single person are much easier. Like, this is why no one talked about, like, the open source, like, maintain, like, sustainability, like, with Linus and Linux, like, because, like, he just makes, like, 1,000,000 of dollars and he doesn't have to worry about there being, like, 40 other teammates who also need to make $1,000,000. But, yeah, I mean, sometimes I mean, there's there were times when I was in the core team and, like, I'm sure someone will quote this to because they're mad at me or something. But, like, man, like, if only just one person had to make the decision, it would have been a lot freaking easier.
Speaker 3:Like, it would have been so much nicer. And, Like, we could have gotten something done faster and, like, when speed matters, like, it can be helpful. And, like, in those situations, you're like, well, why didn't delegation happen? And I'm like, well, who how do we decide who to delegate? Like, it becomes an infinitely recursive situation.
Speaker 3:So it can be hard to move quickly when you have to move quickly and you are seeking consensus, but I ultimately think it is is the better strategy.
Speaker 5:I believe Graydon would have said no to some things that we all like now.
Speaker 2:Yeah. I did get that. Totally fair. Yeah. Well, this is what I mean that I'm not even sure that it's the and I'd Ashley, your point, like, that's not something we've got, so we've gotta figure out a different model.
Speaker 2:Rachel, welcome. I this I thanks again for that talk, by the way. That talk is just so good. I was just relistened to it again recently.
Speaker 3:Well, thank
Speaker 6:you. But there are so many things that I have to talk about here. It's been a fascinating discussion. I think for me, what stands out from a lot of Ashley's comments in particular is how hard it is to deal with nuanced situations. So I I think, like, when you're in a place where, like, there's very clear harassment, there's a very clear violation of a code of conduct.
Speaker 6:Like, we can codify what we do. We can have procedures. We can have a way that we deal with it. Where it's challenging and where we all seem to run it into walls over and over and over again is when it's it's a gray area. Is it somebody is behaving in a way that's not helpful to the community, but it hasn't actually broken any code of conduct.
Speaker 6:Somebody is going in a direction that doesn't necessarily help the community at large. And it's those conversations, those conversations where we have to have tact, we have to have nuance, and we have to think about the humanity of the people on the other side. That's where I think we all tend to get stuck because we can't necessarily have necessarily a forethought plan in terms of, like, this is what we do in this situation. It's more of a, we have to react in this situation. How are we gonna do that?
Speaker 6:How does this all make sense? And I think that's where things get tricky. Does that sound right to you, what you have explained, Ashley?
Speaker 3:Oh my gosh. Yeah. And I think the only potential, like, correction, and I suspect that you actually would probably agree with this, is that more often than not, it's the gray area. Like, the times when the black and white happens is, like, so rare actually that you're kind of, like I guess it was a good thought exercise for us to come up with those procedures because now we are practiced to do it on the fly for all these gray ones. But, yeah, of all the situations that I dealt within Russ around that kind of yeah.
Speaker 3:It it was always like gray, like the the most gray gray.
Speaker 2:Yeah. The black and white situations are so great when they come up to a certain degree. It's like, okay. This is terrible, but, like, we can all agree it's terrible. So it's really easy to actually know what to do here.
Speaker 3:And Honestly, I get a sense now when I think of situations like that because I'm like, you're probably not right. Like, you're probably missing something. Oh, actually.
Speaker 2:Yeah. Yeah. That it's all ambiguity. Yeah.
Speaker 5:It's always easy when it's just Nazis. Oh, you're a Nazi. Okay. Blocked, banned, easy. Move on.
Speaker 2:But the the the common case, Rachel, is that ambiguity that the the nuance. Yeah. It's so hard.
Speaker 3:And I think it comes from a couple of different angles too. Like, one, it's we have to come up with all these processes on the fly now, and there's all the physics of that type of situation. But like especially and this is where the situation with Rust was just getting exponentially more difficult and like at least during my quote, unquote era on the core team, we spent almost all our time on, like, crisis communications and what you might call, like, marketing and PR. And that's because communicating subtlety to a large diverse group of people is almost harder than just dealing with it, like and when it comes like, there's the dealing with the subtlety, and then there's the having to communicate it. And those are they're both just, like, incredibly, incredibly difficult.
Speaker 6:Mhmm. Yeah. We we tell our clients over and over again that the market has a amazing ability to not understand nuance or sense in any sense, but it's especially true when it is, a people situation.
Speaker 3:One of the things that
Speaker 6:I think was really interesting that Ashley was talking about then was the the going back to that feeling of fear and feeling of reaction. Because I I think that it's this balance that we're trying to strike in terms of we want to be transparent. We want to communicate. We want to go quickly. We want to build communities where people feel welcome.
Speaker 6:And sometimes not all of those things can happen at the same time. Like, how do how do we deal with these gray areas where we don't know exactly what we want to do? We don't know what the right course of action is. How do we be fair? How do we be transparent?
Speaker 6:How do we not take this all to a back channel? But, also, how do we not, like, push these people out of the community in the process of trying to figure that out? And, like, that's an incredibly difficult thing to do. And I think one of the things that, like, I don't know if you how you do this, but, like, being some the assumption of intent in this process. Like, how do you make it so that you can help your community understand what it is that you are hoping to accomplish by these conversations in a way that feels fair to everybody and have people assume the best of what's going on.
Speaker 6:And I don't know if you can build that retroactively, but it's something that I think is lacking.
Speaker 3:I think I just I you are so spot on. So this is, like, I guess, ancient history at this point. But back back, I would say, back at Rust Mozilla days, there was a conversation that started in the Rust community around this talk that was given by Aaron Terron and Neko Matsakis, who were the, like, managers of the Rust team at Mozilla, I think, at the time. And it was their prominent leaders in the project. And the the talk was called, like, why wasn't I consulted?
Speaker 3:And it talked about the some community dynamics that Rust was starting to deal with in its RFC process in particular. And there the thing that they talk about, they talk about many things in the talk. I'm I'm sure I also, like, forget half of them. But one of the things that stuck with me that I brought to, like, my corporate career and stuff was that if you wanna have, like, a pluralist, like, consensus seeking community, the number one most important thing you have to do is communicate a clear vision. And I don't know.
Speaker 3:That's what comes to mind when I hear what you're saying, Rachel. Like, there needs to be, like we need to know, like, where you think we're going. Like, where where are we going with all of this? So that I when I gave a keynote with those 2, there was this thing where the Aaron quoted, I think, ESR about, like, all software is like a programmer scratching their own itch and that the goal of, like, communicating vision was so that everybody can itch in the same way. Oh, I think Nico said that.
Speaker 3:Anyways, it was like a really gross kind of visceral metaphor, but, like, really what we were trying to say. And then, like, the last days of the core team as I was on it and experienced, like, one of the things we talked about a lot was shit. Like, we need to be communicating vision more. Like, we need to be doing that, like, leadership, like, work. And what was interesting is that, like, I think a lot of what ended up exploding that was that there were a lot of people who felt very possessive about what that vision should be.
Speaker 3:And I would probably count myself as one of those people and that they're what we discovered was that we no longer had it. And, like, I to what Rachel's point was was like, it's really hard to do that retroactively. Like, we didn't keep up communicating the vision. And so people's vision started fracturing. And then when we went about to say like, oh, no, this is what we need to be doing.
Speaker 3:Like, the problems that we're having in the system we created are because we're missing this one piece. Like, we there wasn't, like, a clear agreement on, like, who owns that vision and what vision should be shared. And, like, I think a lot of folks on teams were like, why should the core team own that mission, like, vision? And, yeah, that's where a lot of things broke down.
Speaker 2:Yeah. Interesting. And it
Speaker 5:It is really hard to identify what the vision is right now. And, like you said, it it's spread across a whole bunch of people on different teams, not just the core team, but each team each individual on each team has their own vision. And, you know, the the thing for me is I probably could live with Rust as it is right now forever. I I don't know of any other features I would need just building on on top of how it is right now. And it's really hard when RFC's come in, because if you're not thinking about a specific feature and you're you're on one of these teams, how are you going to, you know, get up the courage to spend your time reviewing every RFC that affects things you might look at, and then later down the road one of these things lands and you don't you didn't know about it and you don't like it, then you go back and probably the same the same thing has happened thousands of times.
Speaker 5:And and
Speaker 1:I Jeremy, why weren't you consulted?
Speaker 5:Yeah. Yes. Why wasn't I consulted?
Speaker 2:That's right. Exactly.
Speaker 3:Same problem.
Speaker 5:Well, it is There's so many people who who want different things. And I think, you know, that's a very good thing for Rust, but it ends up creating a lot of conflicts and ones that are dealt with after things land, as opposed to, you know, at the proper time.
Speaker 2:Well, it goes to a point, actually, that you made last time about how the that that there is this kind of power of time, and that people who have the time to read the RFC are kind of implicitly granted, a little more power than than those that that don't. And that that that can be a a problem. Florian, you you joined. I know you've got a lot of perspective here. I'd love to get you in here for your thoughts.
Speaker 7:Yeah. I've got the perspective from all the time zones. Time is actually an interesting topic because I think this has been a thing that we've been seeing here and that I've seen on the core team before in much lower stakes, where, for example, things happen with people see something, want to give feedback on it, see it at 11 o'clock at night, wanna go to sleep, and the morning, it's already posted. For that reason, I had actually enacted a rule, or I pushed the court team in the end, enacted it for no communication happens 48 hours, like, unless it's really, really urgent, 48 hours, after a decision has been made, or after something has been proposed to make sure that people around the globe have time to give their feedback. So it's 2 times the globe turning is, really interesting and the they they get a really good approach.
Speaker 7:And one thing that I find interesting about open source governance, we're often talking about uneducated leaders leading global projects. And that's a tough call. And it's I think it's important that given the size that the projects now have, as Ashley has referred to, we slowly start talking about management standards or leadership standards, for also for the sake of all the other projects that need to figure that out the hard way.
Speaker 2:Yeah. And and what and what guidance do we provide those folks? Because, yeah, now you are in a, you know, what does the role I mean, with this someone had asked this question on Twitter. It's like, what does the role of a manager look like in an open source project? And, you know, it, how do we actually how can we kind of encourage the right kind of behavior?
Speaker 2:And, Rachel, I don't need you need you have any any concrete suggestions on how we, you know, that if we all agree that the ambiguity is the problem, are you gonna give us something that is nonambiguous to help us solve all these ambiguous problems? Are you gonna how do we deal with the nuance? Give us something cut and dried to deal with the nuance.
Speaker 5:Someone someone said Boris should be the BDFL.
Speaker 7:Yeah. For the buds.
Speaker 6:Alas, I I don't know if I have anything that is ambiguous here. I I do think, one of the things that I I like that time is the issue here. Like, I wonder if there is coming a tools and ways with kind of this god, I hate to be the one who brings up AI on this, but, like, is there a way where we can start to communicate? So instead of actually saying drop dropping 200 pages of minutes, like, can we make it so that we can have better summaries? Can we start to surface kind of higher level points more recently?
Speaker 6:Like, can we make it so that we have tools that help everyone feel more consulted? Like, maybe that's part of the problem, but that's definitely not gonna solve all of the human feelings. But maybe there are tools on the horizon that can help us better inform people about what's going on. That's a hope. I I don't know if that's actually in the cards, but that would be cool if it was.
Speaker 3:I would definitely share just because we were talking about the RFC process. Like, I super agree with Rachel, and I'll admit, like, I forget where I saw it. I'm sure I saw this probably on, like, Reddit or something, but, like, a lot of people were disappointed in core and, like, didn't think that they were valuable, like, during the era when I was on it. Because a lot of what we did on core was a lot of this paperwork that you're talking about. It was so important, but, like, it was a lot of work that, like, needed to get done, and it needed to get done with somebody who, like, had all the context.
Speaker 3:But it wasn't, like, uniquely, like, interesting or special work. And I I think there's a ton of a ton of this work that probably I don't know if it's AI or, like, some other assistive mechanism. But, like, for RFC, like, the core team and the Lang team, I think, in particular, spent a lot of time with this idea of RFC shepherds, which is, like, the human version of potentially what you're talking about, Rachel, where, like, there would be people assigned to the RFC who would, like, do roll ups and summaries, like, throughout the conversation to try and, like, do this. But here's the problem. And I I think this goes back to my economics point, not to be super repetitive.
Speaker 3:It's just like, no one really liked that and no one really, like,
Speaker 7:I think pieces are there, and we don't need to invent too much. This Week in Rust, the newsletter, is actually a a good model on how you can regularly communicate things every week. And some people that want to drill down to the notes, they do it. Others, they don't. So the question is, what do you put in?
Speaker 7:The other thing coming back to the problem of of leadership education, I get leadership education to my position in my company, and I would love if that were available to, for example, a foundation to, to team members of open source projects because a lot of that needs to be tuned. So one of the problems is that obviously if you get, if you're getting a business education, you're getting education for I lead people that are on my payroll that I can fire and mandate things to, which as hard as it sounds, but in the end, it comes down to this. But, that's the assumption that your coaches are coming from. But on the other hand, you learn, a lot of concepts that immediately made a lot of things click. For example, couple of weeks ago, we had a, training at First Systems where, the coach introduced us to illusion of agreement, which is the group thinks they're in agreement, but they're actually not.
Speaker 7:And that made a lot of things over the last 5 years click. And making these things accessible and also educating people that it's actually worthwhile and that it takes the stress of their work to get educated in that instead of having to figure it out, 1 by 1 and reinventing it, which is a very open source thing to do. I think makes sense.
Speaker 2:Totally. And I I I think that the the a false consensus has been I I I mean, it's been a problem. I think it's a it's a problem in when you are so conflict avoidant, you run the risk of of now overly incentivizing a false consensus because we are trying to avoid conflict. And so people feel like, well, I don't actually agree, but I I just I'm gonna say I agree because I know we we don't have the ability to have the discussion about this disagreement. Or I'm gonna, like, actually, I'm just gonna take a hike and, the because this is just not worth it.
Speaker 2:And I I I think that the, you know, getting the the language to be able to attack some of this stuff directly, which is why, again, I'm Rachel, I'm gonna once again, the point people that your talk about, Laura's asking in the chat, has anyone given a conflict? I talk about conflict avoidance in open source, and I would love to watch it if they have. I do feel, Rachel, that your talk gets to some of this and gives people a common language where they can begin to think about, like, what where is this discord coming from? And I think you were talking about some kind of, I think, focusing on on more obviously bad behavior to a certain degree.
Speaker 7:I
Speaker 2:don't know if you've given thought about I walked to to Laura's question. Has anyone given a talk about conflict avoidance and open source?
Speaker 6:I don't know of 1 if there is, but I would also love to watch it. So I, I will go on the hunt and see what I can find. I think one of the things is, it's when I when I was kind of talking about it's like the two sided thing. And for me that there's challenges both in my ability to introspect and also my ability to communicate in a way that is not conflict avoidant, but also not hurtful. And that's a really fine line to walk.
Speaker 6:And it's even harder if the opposing party is not willing to do that introspection piece. So I do think it is one of those ones where ideally, like, we we as community could all work on this together.
Speaker 1:I wanna try something out in this group. I think some of the mechanisms of communication make this kind of bandwagon effect happen even faster. Someone was mentioning this earlier, but I think that there's this sort of tyranny of the idle where something happens in chat, and the people who are busy kinda don't have time to weigh in, or maybe they'll get to it later. And the folks who are there in chat and responding and awake, and not in some, you know, far flung time zone from the person that it was originally posted can build a head of steam very quickly. And then, you know, not far from being, you know, there's you almost have to exert the effort to get in the way of it, and it's very easy to just let a proposal go of its own built momentum.
Speaker 5:Yeah. This is this is a very good point because especially when you're coming into the Rust project to do something as a third party, usually you have a a reason for it, a business case. You know, I need this feature. I need this RFC, and I need it now. And so you'll push the changes through as fast as you can, and and the people inside of whatever project you're working on, if they don't have time to deal with it this happens to me all the time with Redux because we have a lot of European contributors, and they get annoyed at me.
Speaker 5:They're like, why aren't you merging my PRs when, you know, an hour after I send them? And I'm like, well, I'm the BDFL, and I'm asleep. So so they don't get merged. But if there was, you know, 5 people who all had the ability to merge, they'd merge them while I'm asleep. I'd wake up, and maybe if I'm lucky I would go back through the log and see what was merged.
Speaker 5:If I'm unlucky, I would notice, you know, days or weeks later when something stopped working And I go back and do a git blame and, oh, well, looks like somebody merged something while I was asleep. And that compounds the more people you have on a project who can do this, who who have, you know, commit rights or the right to speak for a project or or whatever rights, and and they do it outside of the knowledge of others, then you build up almost exponentially based on the number of people, this kind of bad feeling of being sidestepped.
Speaker 1:Yeah. The last point I make on this is that I think people have the the feeling that of participation. That is to say, hey, Jeremy, you were in the chat. Brian, you were in the chat. Right?
Speaker 1:Because and and your silence must have been a scent rather than you being on vacation or being asleep or being doing some important work. So you get the as opposed to everyone's sitting in a room or even on a conference call. I thought I thought to to just tune out. Exactly.
Speaker 3:Well, I think it's also important just I think this is maybe what Brian was referring to that I said in the the last conversation that we had. But, like, the way you have power in open source is that you have time. And regardless of any, like, governance structure you could possibly have, like, if you have time, you are going to be able to get so much more done. And so And as and,
Speaker 2:Ashley, there's a great point in the chat pointing out that this is not you need to open source. This is actually true for all volunteer organizations. And
Speaker 3:Oh, yeah. Totally.
Speaker 2:Parent teacher associations and HOA board. And if, like, if it I think all humans will be triggered by one of those 2, either Neil.
Speaker 3:Here's here's the other thing that I would say, though, is, like, open source is kind of at a weird point, and I would also call out that Rust is at a weird point with this. So when the core team was exploded 2 years ago, it is worth noting that over the 3 years before that, it had transitioned from basically 100% full time paid employees of Mozilla to basically a 100%, well, maybe 98. I don't know. Almost all volunteers who were not paid full time in any capacity to contribute to Rust in any way. While at the same time, all of the teams, particularly the teams that and I'm sure I'll get in trouble for this.
Speaker 3:The teams that people think are more important, those teams were getting Pokemon ed by Fang. And this had a really massive effect on the legitimacy and efficacy of governance and Rust. And it's really easy to say oh, do I have an echo? Well, it's really easy to say that, like, oh, corporations are coming and messing up Rust. I don't think it's, like, directly that, but it is worth noting that a lot of governance shifted without anybody really noticing or meaning anything malicious about it when a lot of people had like, a lot of positions lost a lot of money and therefore time, and then a lot of other positions gained an immense amount of money and an immense amount of time.
Speaker 5:It's the same people, but they're they're the things that are funding them, and that's what's important in a capitalist market. You can't eat. You can't do anything, if you're not being funded. So and and, of course, people like Brian and I are are well funded and has no time.
Speaker 2:Like, yeah. Fidgeting uncomfortable in my state here talking about capitalism and rust and working for oxide. The I I would say though that I think part of the reason from our perspective that and I this is where I do wonder how much to kinda lay at capitalism speed. Because, fortunately, there is no company around Rust or company around Cargo. And I feel speaking in, like, in the node community, that when you had companies around node, companies around NPM, then I think things got really ugly really, really, really quickly.
Speaker 2:And
Speaker 5:Just happened with Docker too. Right? They
Speaker 3:Well, those weren't explicit.
Speaker 5:Out all of the
Speaker 3:yeah. Wait. I I okay. So one of the things that I did that made a lot of people really, really upset with me is I advocated for what is probably one of the most basic rules in open source governance, which is that you should not allow, especially because we're a consensus seeking organization, you should not allow more than, I I forget what number I picked, but there should be limits to the number of people from 1 single company that can be on a single team. That rule doesn't exist in Rust.
Speaker 3:There's nothing like that in Rust. And I would just encourage you to look at the team membership.
Speaker 2:Yeah. And I just
Speaker 3:explicit teams around, like, parts of Rust or Cargo or Crate. Io, but there's definitely implicit ones.
Speaker 2:Mhmm. Yeah. And you do get I I mean, I've I've got kind of mixed a mixed kind of reaction to that because on the one hand, I feel that it it assumes that everyone is kinda speaking for their corporate festival all the time, and it becomes complicated because when somebody changes companies, it's like, does that mean they get kicked off or what have you? But on the other hand, I do feel that, like, when you've got everybody on a on a team that is actually also in this other structure, namely this corporate structure that they all have in common. It is a little bit, talk about implicit power structures.
Speaker 2:It does feel like they'd be extreme there or something we definitely wanna avoid. And so, Ashley, how was it? How was that that received? Because I I do feel like and part of what I I I I guess part of of my reaction to that is, like, I I would rather have the principle than the rule. But I don't know.
Speaker 2:Maybe the rule is necessary because we can't agree
Speaker 5:on principle. When I was selecting board members for the Redox OS Nonprofit Corporation, it's I intentionally did not invite anyone who worked for system 76 and the the company I work at. And the reason being that we have a very strong conflict of interest policy, and having any voting bloc be from the same company would have seriously violated that. And, the project is not a nonprofit corporation. It doesn't have tax exempt status by itself.
Speaker 5:That would be the foundation. So the project itself has no legal requirement to do this, but I still think it would be a good requirement.
Speaker 2:Yes. Yeah.
Speaker 3:The thing I would share is to be clear, like, when we set up the Rust Foundation, like, board membership absolutely has these rules. And I think, Brian, I mean, boards have solved this for years. Like, if you lose your job or, like, you change
Speaker 2:No. It's true. Yep.
Speaker 3:There's a lot of ways to handle that type of stuff. Yep. I I've also will say, like, based on the chat, it sounds like people have accepted this. I don't know if it's strictly for the leadership council or if it's for team membership additionally, It sounds like there's gonna be some amount of this rules in the Rust project's governance, which sounds good. When when I shared it, I mean, I think people felt really threatened by it.
Speaker 3:They felt like and I think it was because it was, like, an actual problem and, like, a lot of this hiring had already happened. But, like, people are like, I don't know. Like, can't we just trust each other? And I think this is another interesting portion that I think contributed to Rust. Like, I'm going to say stumbling on this transition, like not making the handoff well is like when projects start, like, early on, like, a lot of it is like, oh, well, these are, like, all my trusted friends.
Speaker 3:And, we don't need, like, policies and rules because, like, I just trust them. And, like, if I set up rules, that would be, like, insulting to them because, like, these are just my buds and, like, I don't think they'd ever screw anything up. And there was a lot of resistance in Rust when I there was like, I had, I had encouraged us to do this thing called the charter program, where it was like, every team should write down, like, what the team's goal is, who the members are, how they get members, and, like, how you leave. And, like, they should have a process of, like, evaluating themselves and, like, whether or not they're doing a good job or not, like, if they're meeting their goals. And that was considered really aggressive.
Speaker 3:That was considered, like like, that was and it was because, like, I I don't think it was I think it was, like, a people weren't being evil or anything when they were rejecting that. They were just saying, like, everybody's a volunteer and working hard and doing their best. Like, why would we want to institute something like that? Like, it would be breaking that trust.
Speaker 5:Yeah. It's just a hobby project. Why do we need to add all this paperwork? But Rust is not a hobby project. It's it's the foundation of a seriously large ecosystem of software.
Speaker 5:And we've seen what's happened when people don't know where it's going or what it's doing. There's somebody doing something wrong, but we don't know who, and we don't know why. And and the amount of public freak out from this is is just incredible. And I can guarantee you, there was quite a lot of internal discussion about this too that wasn't public in the companies and organizations that that use Rust. Like, is this still a language we can trust?
Speaker 5:These are these are people who have done something, and worse than doing something, have not explained why it was done or or who did what or or anything. For a long time, that's that's how it was for for days. And so, basically, you know, at system 76, at Redux, everything I'm in I'm involved in, it's, you know, what do we have to do? And if Rust is no longer a marketable element, you know, do we have to pivot away from things just to because there's public backlash? It's it's quite a lot of damage that can be done.
Speaker 2:Yeah. So it depends on yeah.
Speaker 7:Come off. Like, it's it's a multifaceted problem. For us, we've always been a small company in the space. It has been a huge problem that there was no clearly communicated expectation of what it means, to be, for example, how to take over a team leadership. I can't account for that, and I need to account very shortly.
Speaker 7:I don't have a $1,000,000,000 runway, so, I have a one that is counted in $20,000 or more. And, for me, it also became a huge issue at that point when I was actually in the core team representing the project at the Foundation's board while also being managing director of 1 of the members, that people would check me up in company calls on my positions on the core team and on the foundation, which is also one of the reasons I retreated. Because the moment we would run even into the perception of a conflict of interest that would be extremely damaging, to our profile. And, that just became became too complex. So, these rules are not only internally, but also externally.
Speaker 7:And to add another point, if you can't communicate, hey. We would like to participate in leadership of this team, and the project says, well, that needs at least 10 hours of work a week. That's actually something I can take to my boss rather than, hey, are you okay if I'm team lead here? Yeah. Sure.
Speaker 7:You can do that on the side. And later, you discuss what on the side means, and they probably meant 2 hours and not 10 or something like that. So having firm agreements around that is interesting for smaller players because then they can, account, for for that. Sorry, Brian.
Speaker 2:So we, we gotta run. I unfortunately, we got, this is a challenge during to this time. So we got a hard stop here at at 10, and, of course, we're in the new, era of remote work. And if you're, you know, 2 minutes late for a meeting, people assume that you're dead. So, we are do need to run this has been a great discussion, Ashley.
Speaker 2:Thank you so much. And Jeremy and Rachel and and Florian, great from Adam as well. I I think that, you know, this is tough that this is tough stuff. I think the point was made earlier that, part of the reason that this has been tough for Rust is because a lot of people really care about Rust. And, I would also say that that one of the things that that that this has been a difficult issue for us kinda to to process from a leadership perspective.
Speaker 2:I do think that broadly, this is a community that, that sees eye to eye on a lot. So, I think that it it would be hasty to, to walk away from a lot of terrific elements of this community. And, indeed, I think we'd be falling into the trap of overly avoiding conflict as opposed to actually, like, looking at me eyeballs. And, if you did take one thing away, I would really encourage you to watch, Rachel's talk on the introspection cap. And I will, merits a rewatch, if you've already watched it.
Speaker 2:So, thank you again, everyone. Ashley, thank you especially. Really appreciate it. And, now I'm gonna need to go communicate that I've not been lost at sea to my to my next meeting. Thanks, everybody.
Speaker 1:Thanks, everyone.
Creators and Guests
