There's a couple of devices, there's probably some AI's listening to us, but this is actually
they talk for us as people, and I was an amazing bunch of events before the conference,
and one of them yesterday during the workshop, I overheard across the room somebody showed
out, we are developers, not humans, and I tend to disagree.
I think we're humans first, even if we do stay up late, drinking up Clibmata, like we do
in Germany and Berlin and everywhere else, but what I want to talk about, if I can get
my slide to work, is finding ways to reframe our work and open source as compassionate
activities.
I'm not going to talk too much about the importance of finding peace and being gentle, we
can still argue.
I think it's important to find the right names for things, and I'm going to be coming
back to that quite a few times in the book.
I mean, my name, Daniel, I earned that name, but I'm meeting because I was in a meeting
with another Daniel, actually this was in Germany, so there was a Daniel in a Daniel
and the person who was taking notes at the meeting didn't know our surnames, which is
why I didn't tell you my surname earlier.
I Daniel, but she didn't know how to write that, so she used the phonetic spelling that
she would use in tuning in to differentiate between one Daniel and another Daniel, and
I've never made it a topic of a talk to discuss why we get names that we used to talk
about things.
I think a lot of it is accidental, right, like bus factor, right?
Raise your hand if you don't want bus factor is, it's about half the room, so I'll try
to describe it in a gentle way, bus factor is when you're walking down the street and
you get hit by a bus, you end up in the hospital or the grave, that's what it needs.
In software development, what we mean with bus factor one is the number of people that
have to get hit by a bus before your system start to fall apart.
That means that one individual has all the knowledge of an organization, probably not a good
thing for the longevity of an open-source project, if it can be derailed by one person
leaving an organization.
I've heard there's a new word in town called lottery factor, and this one is, I think it's
even more interesting than bus factor, because it means that if somebody on your team wins
a lot of money in the lottery, they're just going to leave.
Money is the factor, just like getting hit by a bus that's going to stop you from contributing
to open-source or working on the project.
I mean, I think that if we were to use one of these terms to talk about the problems
of losing people in open-source, then maybe we should choose the gentler one of, hey, you
want the lottery, congratulations, see you next Tuesday.
That's because you want money, doesn't change who you are, doesn't change what it means
to be a part of a community, leaving the planet does.
So if you stop talking to people, they don't know what you're doing, they don't know that
you're not around, they don't know why you're not around.
In community building, I wish I had a joke from the community TV show I don't, but all
of community is about relating and relationships and collaboration, and you can't collaborate
if you don't talk.
So I'm ashamed to say there's been times when I've ghosted people because I didn't
know what to say, right, I think I've been on receiving end of that too, and it's hard
to overcome, but ghosting is another kind of bus factor, right, it's this is for some
emotional fear of not being able to relate, right, and overcoming that challenge is really
hard if you're doing it alone, right?
So we come back to this whole idea of, well, there is no bus factor, there is no lottery
factor, there is just a group of us working on something together.
That's why what we've tried to accomplish in our community is to just keep on checking
on people.
If you don't hear from somebody, say hi, don't be that person that says, oh, you were supposed
to contact me and you didn't, so I'm not going to contact you.
It turns out that people aren't always, mentally, well, maybe they have problems, maybe
there's things in their family, maybe it's about their job, maybe they're overworked,
maybe they're suicidal, and I think the challenge for leadership in open source projects
is remembering, you can't do everything yourself, you have to have a group of people
that you're working with and that you, that we're all accountable to each other, and this
is a really nice, a nice hack, maybe the salient point of this whole talk, the one that
gave me the idea for this talk, and that is to engage the painful parts, right?
So, everybody here knows what imposter syndrome is, do you know imposter syndrome
as your hand?
It's almost everybody, okay, for those of you on stream, who, maybe raise your hand
as well, imposter syndrome is the feeling that you don't know what you're doing, you're
not good enough at what you do, and people are judging you.
That's a pretty decent summary of imposter syndrome, and then there's the other side of
the imposter syndrome.
This is the side that turns into entitlement, who here knows what entitlement is and opens
our software, issues and poor requests, right?
Entitlement is like the same term as bus factor, we shouldn't use it, because what we're
saying, let me say, oh, don't be so entitled, is we're judging that person for how they
want to try to interact with us, and honestly, in every community, there are people who struggle
with birds, maybe even native English speakers struggle with birds, and I know in German,
I struggle with German, and in French, I struggle with French, and in Italian, I struggle with
Italian, and I don't always say exactly what I want to say, and that can be frustrating
for me as a speaker, and actually that problem accompanied me for the first seven years,
I was learning German, I was always angry, but at myself, because I couldn't say exactly
the thing I wanted to say, and when you have an issue pop up in your repository, and it says
something like, hey, I found a problem in your code, why don't you even fix it, because I
need this to be fixed for my project, and most people in our community would just take 100
of time for this, kind of entitled person, who do they think they are? They think that there's
17 minutes left in this talk, they think that the problems that they have are suddenly my problems,
and in a sense, and I'm going to argue that they actually are, and I think it's important to
engage people who you think are acting entitled, because if you don't, you start to ghost them,
you start to show them that they're not important, and that you're actually framing your community
in a way that says some of us are better than some of us, and you create this type of polarity
where some of us don't feel empowered to contribute, right? So when I'm talking about
challenging yourself to address that person, the strategy that I've adopted is when it's
called to anyone's attention in the community that someone is misbehaving, I will go look at
the situation, try to stay neutral and detached, and find a private channel to talk to that person,
whether it's in the real world, maybe it's a coffee shop. If it's discord, then a DM, if it's an email,
then I'll write them an email. I am, however, acting as a servant of the community, so I do document
these conversations, and I share them with the rest of the mod team, the communications,
between each other is important, because generally speaking, someone in our community's self-assented,
and I don't always know if that was intended, maybe it was, sometimes it is.
Generally speaking, people learn to wear that they're behaving in a way that doesn't feel appropriate
in the community, and that's why as a warden of the community, it's important to just talk to people,
find them, meet them where they are, talk to them, and hold everybody accountable to this. I think
that at the beginning of this devroom, we heard some rules about being kind to each other,
and if you have a problem, you raise your hand. In posters are the people that don't succeed.
Are you an imposter? No, an AI might be an imposter, you are you, you are good, and everybody in
your community is also good. The default mode is this is a good person who has interests, they might
up in mind, but that's okay. If we deconstruct the word imposter, we get imposition to impose.
Having the imposition that you're not good enough, that you can't communicate well enough,
that you haven't talked to that person long enough, are reasons why you should get over it.
If you can't get over it, what should you do? Ask for help. If you're not able to listen to
someone asking for help, you can help yourself. I guess the campaign I'm on is that money isn't
going to make open source better. Lottery factor or not, paying maintainers is not going to solve
the real problem of open source. The real problem that open source faces is the motion above you.
I don't think that we pay enough attention to the damage that we endured as individuals
and in this context, how can we understand what other people are going through?
Then we have to judge them and all the while we're judging ourselves in poster syndrome.
Are we just using the words that we're given to us and not paying attention to what they're
actually doing to us? Do I have imposter syndrome when I'm trying to debug rust?
Absolutely, but I have the compiler. Thank you very much. She helps you. I have friends.
If we can tell me how wrong I am in a loving but harsh way. It doesn't make me imposter.
I'm a learner. I'm getting better. I don't know if the system we build to tell
is the perfect one. I'll try to outline how we build the whole organization. It started with
two friends and then we got more friends. We had a core team of like five or six people but then
more people started coming with questions and issues and pull requests and then some venture
capitalists said, hey, do you want to make some money? And we said, oh, so we joined the comments
Conservancy. We created a program within the Dutch Foundation to protect the world's
stewardship of the code and the license of the project. And one of the mistakes we made is we thought
that the governance body was good at making decisions. The governance body is really good at
paper, tiger's ship. If that's a word. Like at being the responsible legal entity in case
you need to do things like fight red bull for the trademark of teller. Which we did, we came to
it a good. But it's not going about deciding what the API should look like. And after a year of just
insanely long meetings and not getting anywhere we empowered the working group to do two things.
One to vote in or out the people on the board of directors. But two also to create individual
work streams of people with particular skills. So there's an ops group, there's a security group,
there's a dev group, there's a comms group and they kind of change as people come and go.
And people come and go. I think every community has this fear of not having enough people to work
on the project. And sometimes projects and people shouldn't. I think the great part about the
teller community is that through the teller community I've joined other communities and made other
friends. And I think that I haven't met any imposter. I've been doing this for 20 years. I haven't met any
imposter. Not a single one. I see a room full of people who care about people. I see people
that I've worked with before. People that I might work with in the future. People who are going
to tell other people that you're not an imposter, there's no bus factor. The thought I'd like to leave
you with is that good governance of ourselves as individuals implies that we can govern as a body,
as a group. I'm not talking socialism or communism or democracy or anything like that.
I'm just talking about open-source communities. If we look at everything as a contribution,
some contributions are good. Like, hey, the thing you just said, maybe we could try to reframe
that because it seemed a little means to me. That's what you do when someone files a pull request.
You're like, I don't like, you know, I don't like tabs. That's why we use lynching. So please,
next time, when you make a pull request, run the winter. You don't have to like tabs or just
like tabs. You can change it yourself. But as a community we all agreed, we don't like tabs.
And if that changes in two years to be four spaces or to be two tabs, that's a thing that will
we decide. And my point is that we can, if we are developers, not humans,
at the very least treat other people as if we were talking to code and use the same rules of
engagement that we've used to build codes to also build our communities. That helps us stay transparent
and accountable. Friendly, accessible, honorable, maybe, and more communicative. I think
when we stop talking to each other, it better because better be because one of us is dead,
not because we're angry, not because we feel disenfranchised. Like, my goal here to
to pep you up for the rest of this amazing Boston, the beginning of the community
devroom, is to just remind you that we can do all of this stuff together. We can be better.
We don't have to run away if we're afraid. And so I guess the final point I'd like to say is to
be good to each other. Listen to my podcast. It was just a wrap last night about Tauri over at
I know that. And I know I have seven minutes, but I also wanted to leave a couple of minutes at the
end for you to ask me questions if you have them. Yeah. You're talking about entitlement
to people in that way. I don't write wordings, but there are a lot of post-banned players out there
right. They're just going to suck things away. How do you balance that? Okay, the question was
with regard to entitlement. There is the perception that there are health vampires out there.
And how do you address a health vampire? You can't ghost them. You cannot. You should not ghost
them. My point is that you just address it head on and call a health vampire.
Maybe not, don't call them a health vampire. Maybe the thing to do is to say, hey, you're asking
a lot of questions that's great. Can I interest you in some documentation? In the rust community,
we have slash examples. These are great places to have you tried rust things? Are you looking
for a coach? Do you want to hire a trainer? And people will kind of recognize that they're doing
and be like, oh gosh, I don't know. And I see this happen a lot with interns, junior developers,
especially people that just kind of job and haven't been doing community work ever. And like,
yeah, you're my stack overflow. You're my chat to PT. Come on, help me out. Don't use chat to PT.
Or plot or anything for that. I'll get to you. I see you in back there. I'll get you in a second.
The reason why I say that is you are disenfranchising your mind. You're disengaging from that
person. All you are really doing is pretending. So, engage, honorably, honestly, and then let them
recognize that their behavior isn't perfect. So, in the back there was another question.
Yeah, so, following up on that, beyond how them hires or whatever, there are genuinely
negative people in the community. That is an unfortunate fact of the human condition.
How do you suggest, and I'm sure engagement is part of this, but how do you suggest that
we as community participate? Do you want people who are genuinely toxic in the digital world?
So, the question was, how do we as a community deal with people who are genuinely toxic in
the digital world? Because there are negative people. I wanted to say Nancy, but that's not fair.
I'm going to work backwards. First of all, hammer band. Do you have the obligation to protect
your community, and if somebody won't change their aggressive mean behavior, you ban them from
the community, when they come back, you ban them again. Document everything. And not because you're
going to file a lawsuit, but it's because if you start with a hammer band, nobody knows what's happened.
You just deleted all their posts, whatever. Document it so that you can share it with your team,
because that's the compassionate thing to do for your team, because it shows them that you
did what they expected you to do before the hammer band. You address this person privately.
If they don't react, what's they will if you ask them if they're a bot? Are you a chatbot?
People who are mean hate that, because they want to be heard. That's the last step. That's my last
resort. If they're saying, no, I'm not a chatbot. I'm just really mad at this guy, because he said
this thing, by talking to them, I can unravel what happened. Maybe it has nothing to do with the
code or the community. Maybe they're having a bad day. And engaging with someone like that is
hard moderation work, but what it does do is it shows people that you care enough to listen to them,
but you also have the big old stick. And you're going to ban them from the community if they don't
live up to the expectations of the community as written in the guidelines, because the guidelines
are what holds the community together, not the open source license. How will you agree to participate
and communicate with each other to find who we are?
So, all of that takes a lot of time. And so, all of you make sure that you have something
ready to commit to an aspect of the time, because it's not always as involved, and you have to do it
poorly. And so, all you do is make sure you do that all the time.
The question was, all of this takes a lot of time. Being a mod is a thankless job and how do you
make it sexy? I mean, I'm kind of reframing the question. How do you attract people to this?
And I think that people are attracted to it. By posting the wrong thing on Reddit,
one of our greatest contributors to the community saw something I don't remember who wrote it,
doesn't matter, but it was obviously wrong to anyone who's been using rust for more than 30 minutes.
And then they came over to tell us how wrong we were and ended up becoming one of the most
prolific contributors to the project. And one of our, I don't want to say thought police,
because it's not about policing people, but it's about being sensitive, and following the
the stream. I mean, with 15,000 people on our discord and six years of chat history,
I've been out of line two, and people call me on it, and that's okay to also get calls out.
Right? Don't run away from the problem and change it. And I think that if you
care, you're going to stick around, and no one walks alone. Bus factor or lottery factor or whatever
you want to call it, it's not a community if you're doing it alone. That's a charity.
So, one last question, have 30 seconds? Yeah.
The question was, what does it mean when a project is over, the project is over when no one can maintain it?
What there is not enough knowledge of how the project was built or maintained,
specifically with regard to secrets. So, if the secrets are lost that hold the NPM keys,
all you can do is for you. Thanks.