 Hi, everybody. Welcome to what makes open source communities thrive remotely. My name is Eva Black. My pronouns are they and them. I'm currently the open source program manager for Azure Confidential Compute. I work with the Confidential Meeting Consortium, it's a Linux Foundation project. I also work in Kubernetes and some of you might have known me when I worked on OpenStack, or before that, my SQL. Well, today I'm going to share with you some of the things I've learned and some of the things that this community has taught me about how open source communities thrive and how that knowledge can be taken back into our companies, our day jobs, or even our social groups and help us survive this new, very, very distributed world that we live in today. Before I jump into open source, though I want to talk a little bit about the very first company I ever worked in back in 1999. First I had to call it, I joined a little gaming startup, mostly devs, no managers. Most of us didn't know what we were really doing. And I committed a lot to go down to Santa Monica once in a while, once or twice a week. We were all gamers. And so we'd all just kind of hang out after hours together in EverQuest, before World of Warcraft. And we worked long hours, sometimes random hours. We rarely had team meetings of the sort of like sit around an office or a whiteboard. And I've wondered, as I prepared for this talk, why did that seem to work so well? What have I implicitly recreated in other teams I've managed since then? And what stands out as I look back is that we bonded through a shared distributed experience, that after hours gaming, occasional dinners or happy hours, but a lot of the online interactions we had were connective in ways that a pure work environment might not be because we're all gamers. And we relied for work very heavily on asynchronous communications, chat systems which were normal for us as gamers, file shares, file drops, Wikis, again, things that we all had prior experience with as gamers back then. We also use the same tools for work. And we would schedule office time if we needed to solve something more challenging, needed a high ban on communication, if there was an HR issue, if there was a team, you know, big disagreement, we'd get on the phone or we'd all just drive into the office and schedule a Friday. And I didn't wanna just talk about my experience with that company or what I learned in open source. I wanted to bring in other perspectives, so I did the only sensible thing I tweeted and I asked for my friends, people that I'd met through open source to share their experience with me. And in total, I had almost 20 people reply and some of these spun off into further conversations. Folks that have been, you know, just joined open source in the past couple of years do some folks who've been doing open source for more than 40 years now before the term was even coined. Company founders, doc writers, people from a whole bunch of different communities all responded to me. And I do wanna call out a gap here in the sort of the virtual dataset that I collected. My Twitter following and my open source community doesn't reach that well into East Asia and not at all into Africa. And so I don't have any data for the ways in which people from those parts of the world or cultural backgrounds really connect in. That's unfortunate. And if anyone after this talk has those connections or insight there and wants to reach out, I would be so grateful to learn. So from all that data, three common principles emerged. That individual work is more challenging if you're coming from a traditional office environment into a distributed environment or an open source team, that is a barrier to entry that is a hurdle that we could work to get over. That in a decentralized team where you're not seeing each other, you don't have social grooming, your team cohesion degrades over time. And I'll come back to define that term that I just dropped, social grooming. It has a sociology context that I'll bring up in a bit. And then really that every person, every individual, every circumstance is unique. And so flexibility is key, both from your manager and flexibility and empathy with yourself is also key. So I'll talk for a few minutes about individual adaptation and techniques that have helped me and have helped friends and peers of mine that can be done by anybody who is moving into a distributed or decentralized work environment. The first and perhaps most important individual thing is to do everything you can to maintain a work-life balance that suits you and your needs. I've found having a separate office space with a door at some points in my life to be incredibly valuable. That is one of the most consistent pieces of feedback that I got. Being able to go to work while you're at home but still close that are behind you. And not everybody has the privilege to have that much space at home. But if you do, it's really great. What I've done for myself right now is I bought a 400 bucks, I bought a divider, a little four piece partition that folds up. And that can partition off part of one room. So there's just a visual barrier from the social part of the room to, okay, I walk around that, I sit down, I'm at my desk, I don't see my bed or a couch anymore. I'm just at work. And when I leave that, I walk around the partition and now I don't see my desk anymore. And related to that, several folks said, yeah, don't take your laptop to bed. And like, who can say we never do that? Come on. But I try not to. And I've gotten pretty good. I don't think I've brought my laptop to bed in at least a month now. Now for folks who are accustomed to commuting to work, a lot of folks said they used to have a ritual for this. Might listen to a podcast or having a phone call with a friend. And while we're all working from home, those are gone. But plenty of folks in open source and in my open source community said they have rituals that they have still created for themselves, which might be go for a jog, run around the block, do a little bit of exercise. And there's still a window to listen to that podcast if you wanted to. Find ways to recreate whatever your sense of normal was pre-COVID or in an office. If you're moving into a work from home distributed team, those rituals are still core to your mental health. Find ways to maintain them. And account for your own variations, both within a team, you're managing a team, everybody has their own schedule or for yourself as your life changes and your life circumstances change. Those variations come and go and you need to be able to adapt to them and have the right social supports to adapt to coffee break in the afternoons. And that might be when you normally see people, try to recreate that in your distributed environment. And accessibility is key. An office functions to normalize, that is to make standard and consistent the work space that everybody has. And if you have an accessibility need, different type of desk or keyboard, well, hopefully HRs are to give that to you. And if you're working from home, hopefully they're still able to get that to you. This is one of those areas where distributed and open source community is I've seen often struggle. Oh, we sent you a laptop, isn't that enough? And for a lot of people know, we also need a monitor that's elevated or wider and ergonomic keyboard, things like that. So it's very important to be able to provide that. And what about accessibility in terms of recreating our socially connective spaces? Could we do that through VR? Maybe, I haven't seen it work yet, but I'm hopeful, it'll be fine if it works. But this doesn't solve everything. Again, there's so much individual variance here. I can't talk through everything on this slide, but being able to and supported as we create accessible, workable environments in our work from home space, especially challenging if we are working from home with kids, I myself am not, I can't speak to that, but plenty of respondents shared their suggestions and a common, a really common theme from folks who are working from home with kids is, again, have the dedicated office space, have a co-parent or someone else who can help, if you need to record something for a conference or jump on a meeting, have the social supports to be able to do that that are so essential. And now I'm gonna spend a while talking about organizational adaptation. And this is really for if you are taking a team that is accustomed to being in an office culture and moving to a decentralized culture, whether that's because of COVID or you're changing your team structure anyway, this is where you can hopefully learn a lot from open source communities. And I'm gonna start with this theory that an anthropologist named Robin Dunbar came up with in about the mid-90s, that the amount of, he was studying premise, I should say, the amount of time available for social grooming between primates determined the size of the primate group and that a higher investment of time between members resulted in a tighter bond to move towards these inner circles. And that the maximum tribal unit was 150 to 300 people and we see that in open source communities all the time. OpenStack went through that evolutionary tipping point. Kubernetes has gone through that. Ubuntu went through that before. MySQL even before that. This is very consistent. The same thing happens also in company organizations. At about 100, 150 people, it's too large for most members of the group to know each other anymore and have the familiarity to know what someone else is working on to recognize them in a crowd. And we work best with people in these smaller groups where we know each other better. We know that we're working towards the common goals and have the same language to describe them. And in every open source group I've ever been in, teams have experimented with this balance of how often do we meet and how large are our organizational groups. And what we found consistently is that we need face-to-face meetings about every six months. That has been true both in distributed companies I've worked in, there were two of those that had no central office and three different open source communities. And the only exception to this that I've ever found has been in online gamer communities. Going back to that first company I worked at and ever since then, my hypothesis is that game communities have through practice and immersion in a virtual world, a game world, they've recreated social grooming in that context. Whether it's gifts of fresh baked pies in your game or whatever it might be, these little social kindnesses maintain those bonds in ways that we could do if we were in the office together taking each other out for lunch or having coffee in the afternoon that we cannot do just automatically in a decentralized environment. And another aspect of this as well is that a flat org and many decentralized groups try to become a flat org has a communication tax. Any team above about six people becomes unmanageable. This tax becomes unmanageable and eats away at productivity. And I have seen myself and I've tried different approaches to solve this, different hierarchies. None of them really work that well. And part of the reason has been that unintended clicks form in decentralized teams and that affects everybody. Any imbalance in communication bandwidth prioritizes and benefits some people that have higher bandwidth over those who do not. So imagine, if you will, there's a team of eight and six people live and work in the same time zone and two people work five time zones away. Well, if people are using synchronous communication Zoom calls, phone calls, instant message like Slack and they're just chatting all day long. The people who are five time zones away effectively only have three hours of overlap assuming that they work the same hours in the local time zone. And that means they are at about a 60% disadvantage to sharing knowledge, both giving and receiving. It's not their fault that they're going to suffer, but they will. And this has to be addressed at the hiring level at the organization level, the management level by balancing the bandwidth. And I have found two approaches that have worked. You either mandate the use of shared communication systems whatever the least common denominator is. If it is an actual bandwidth issue which could be accessibility, it could be, for example there, imagine those five people are in a conference room and two people are working from home over a bad intercom link. They will not be able to hear and participate in conversations as well because of the technology barrier. I've seen this solved by telling everybody, go work from home or go work from your desk with a headset. This has now created a common communication bandwidth that everybody's on the same equal footing. Solve that problem. Another way is to organize teams so that it balances the communication time. If nobody is sharing the same time zone, there's no click, there's no nexus of a majority of people in one time zone, then everybody learns the right tools to be disaggregated, to be asynchronous. Whether it's email or documentation, I'll get to that in a minute. Now there could be other solutions out there to balance the bandwidth. But these are the only two that I've seen actually work. Excuse me. Now for the rest of this talk, I'm gonna talk about some real challenges in organizational adaptation. How do we actually reduce that communication tax through documentation? Document everything. Anticipate that documents will age out. Use a standard template that specifies the doc owner, the creation date, the change date, the change history. If you need sign-offs when those sign-offs were required, document your plans, document your architecture, document your reasoning for decisions, document every meeting you have. It sounds tedious. It is critical. Cannot be overstated. And I have no suggestion as far as what technology to use a plain text file, Google Docs, whatever works for your team. But organizationally, you need to internalize the documentation is how you parallelize the effort of knowledge distribution. It's not one-on-one. It's not a live meeting where one third of your team doesn't get to attend. It is by writing it down and sharing that that other people are able to learn at their own pace on their own time, in their own time zone. And if you do need to have a meeting to solve something at high bandwidth, write the doc ahead of time and set aside the first 15 minutes of that meeting so that everybody can read it. Because there is no point in having the meeting where only half the people have read the document and only half the people can participate. If the other half, if their opinions aren't needed, they shouldn't be in the meeting. And if their opinions are needed, show them the grace of giving them time to read the document when we're all busy. One final note on documentation and meetings. I know some work like to record their meetings and think that that's enough. It's not. Recording is not searchable, indexable in the same way that a document is, nor is it versionable. So once again, please, documentation is the solution to scaling out and scaling out a decentralized team. It follows from this that people who write good documentation are force multipliers for your team, whatever your team is, whether it's an open source project or your company's product. And this work must be valued. It must be rewarded for it to happen. We get what we incentivize. We get what we measure. So if you do not measure and reward documentation and specifically hire for that skill, you will struggle to scale out a decentralized team. As open source product leads, I will say that we need to value that documentation, that contribution we need to reward it on the same and equal footing as the code in our open source communities. I hope that is not a controversial opinion anymore. And to support people in a decentralized environment, this is something that open source communities have some done well, some not so much, but it is especially critical now when we're not able to meet every six months. Project leads should be prioritizing contributor wellbeing through a variety of tools. We'll get to that in a second. And managers, you should also be organizing your teams to support that cohesion, giving them time, creating spaces for them, for your employees to come together socially and a time with you if they need anything. Now, what could this look like? What avenues do we have to bring our whole self, whether to work in a company or in an open source community? It's things like a video on happy hour or a tea time or a coffee chat in the mornings. Have a consistent, friendly face there that welcomes people in, makes them feel included in the space. It is that sense of belonging and safety that we need more than ever today. This could be a game night, trivia, scrabble, I don't know, whatever you like. It could be a book club. And if you do choose to do a book club in your company, like rotate around, who gets to pick the book and the topic? Whatever works for you and your group, community or team to support a decentralized community, especially when we cannot meet face to face every few months, make time for the same connections that we have lost. And these days, our chat is our culture that is nowhere more true than an open source community that lives on a mailing list or on IRC or on Slack. But it is especially true for all of us nowadays. And we should encourage the use of public channels, right? In a large forum, people tend to be nervous and afraid of judgment, especially from those they don't know or those who are their superiors. It's just as true if your CEO is in that channel as if your, you know, your Kubernetes steering committee or your OpenStack technical committee is hanging out in there and you don't know them and they might be judging you. So team leads, it's up to you to make these public spaces inclusive, welcoming and warm and help people overcome their tendency to revert to one-on-one private conversations. That is a huge part of our social cohesion today. And encourage natural chat styles, maybe in the main channel, maybe a separate channel, share cat pics, I don't know, whatever works, be human, show each other who you are and connect as humans. Lastly, I just really wanna bring this point home. Making our spaces inclusive so that people have the confidence to feel safe, being visible as who they are, their whole self. That isn't just about finding a few people from different demographics and bringing them in, that's diversity. Inclusivity is then having them stay and feel welcome and included and safe. I mentioned this quote here from a recent report on decrypting diversity in Infosack. Probably applies, a lot of the same things would apply to any community in tech these days. There's some really good information in there, you can just Google search for that report. And from the community folks who had reached out to me, I do want to say a special thank you to a bunch of them for their time and their input in this talk and for all the writing that they've done on the same topic. So if you wanna go do any further reading on this, there's some great resources there. Thank you all so much. Find the online questions, I'll be here for Alfred Chat. Bye.