 Good morning, everyone. Can you guys hear me? Awesome. All right, so welcome to day four of scale. How's everyone like it so far? How's everyone like the new venue? Do you guys like the new venue? Yes? Awesome. All right, so I have a couple administrative announcements this morning. So this morning we have our LPI and BSD testing and those are gonna be in the rooms behind me, INJ. We were also, oh, if, for anyone interested in taking the test, if you happen to pass it today, you can visit registration and while supplies last, you might receive a special prize. It's pretty exciting. We're also going to be doing a giveaway after Sarah's keynote. So stick around. Some schedule changes. The session that was going to be in ballroom F in the new to scale track at 3 p.m. Has been canceled, unfortunately. The speaker is sick. So the 430 session is now going to be at 3 o'clock. Because it's a tech conference, I have a small little technology tidbit of information. So this year we had a 200 megabits internet connection and you guys used all of it for the whole weekend. So nicely done. 50% of the traffic was actually IPv6. So also nicely done. Our registration, because everyone's curious about registration, this morning we were floating around the 3,500 mark. So thank you for that. That's all my announcements. So I have the distinct pleasure of introducing our keynote speaker this morning, Sarah Sharp. Sarah is a Linux graphics software writer, developer with Intel. She was a kernel developer from 2006 to 2013. She's also the co-coordinator of Outreachy. Without further ado, Sarah. Good morning. Did everyone enjoy the games night last night? Yeah, I loved it because there's like little kids running around. I got to talk to a 12-year-old while I was playing with Legos. And I really like scale because I see a lot of diversity here. I see a lot of women. I see a lot of people of color. So I wanted to do a quick little poll and just raise your hand if you're a male in the audience. All right, now keep your hands up. Keep your hands up. Also raise your hand if you're white. All right. Now that all your hands are raised, repeat after me. Increasing diversity in open source is my responsibility. Why is it your responsibility? Because all too often minorities in tech have to shoulder the unpaid emotional work of trying to increase diversity in tech. And we all need to look at our privilege because our privilege shows us the ways that we are unconsciously biased. Each of us has identities and skills that society values. And some of us have identities that society discriminates against. So I've looked at my own privilege. I did a little bit of a brainstorming session on Twitter and said what are all the different ways that people could be privileged? So on the slide, my privileges are in bold black and the ways that society might discriminate against me is in red. And I challenge you to do the same sort of exercise for yourself and find out where you lie because it's interesting to look at where your privilege is. Because we look for people that are similar to ourselves in tech and recognizing that we have privilege means that we can seek out diverse voices. And I know in open source, we like to talk a lot about this word meritocracy. Meritocracy in open source means anyone can submit code. Anyone can go and submit a patch upstream and people say I don't see people. I just see code. However, there's a study from MIT that they took a bunch of people and they gave them a description of a company. Some companies were described as meritocratic and some companies weren't. And they asked them to give bonuses to fake employees who are either male or female. And the funny thing was is that the companies that were described as meritocratic, the people gave more bonus money to men. When they were not described as meritocratic, the bonus rates were about equal. And part of that may be because when an organization is described as meritocratic, we make excuses for why there's disparity, especially why there's disparity in tech. So each of us needs to look at our privilege and our unconscious biases and figure out how we can change those. And we'll talk a little bit about each of them. And there's a lot of different ways that each of us as individuals can help diversity in tech. But I want to look at kind of the broader sense of how we as people of open source communities and contributors, developers, can also increase diversity in tech. And that starts with a man named Abraham Maslow. Now Abraham Maslow was a teacher at Brooklyn College and he in 1943 published a paper called A Theory of Human Motivation. Abraham was very interested in how successful people actually got to achieve their success. So he studied people like Jane Adams, who was part of the women's suffrage movement. He studied people like Albert Einstein. He wanted to know how did these people achieve their fullest potential? And this is something that's interesting to us because we like those kind of people in our open source communities. So how can we help the people in our open source community achieve their greatest potential if it's anything from writing the next feature in Java or writing the best documentation, doing artwork for our projects? How can we help them achieve that potential? So Maslow talked about a hierarchy of needs that was necessary in order for someone to achieve their greatest potential. And we'll talk about each of these needs in detail. But the important thing to note is that each of the needs on the lower levels must be met before the next need can be met. So for example, if someone breaks into your house, you are going to focus all of your energy on making sure your possessions are safe, fixing the broken window. You're not going to be focused on your job, on being a part of an open source community. So that need for security must be met before any of the additional needs can be met. So let's talk a little bit about Maslow's first level of needs, homeostasis. Homeostasis is basically the idea that all of your functions in your body, all of your systems are working right. Your respiratory systems working, your digestive systems working, everything's fine. So what do you need in order to make sure that your body is in homeostasis? You need warmth. If you're freezing, you're going to focus all of your energy on getting warm. You need food, you need water, you need something to drink. And then once you've had that food and water, there's also the need for excretion, because everybody poops. And some people might laugh and think like this is such a basic need that, you know, why am I even talking about people being able to use the bathroom? The problem is there are people in our society that actually have trouble finding a safe place to use the restroom. So there are a lot of trans people in our society that face harassment every time they go into a restroom. A study of DC trans men and women showed that 70 percent of them had been harassed in some way in the bathroom. 68 percent of them reported that they had experienced verbal harassment. 9 percent of them reported that they had been physically assaulted, including sexual assault in a restroom. 18 percent of them reported that they had been denied access to a restroom because of who they are. And this led to physical complications. 54 percent of them reported either dehydration, bladder, or kidney infections, because they didn't feel safe and they were holding it all day. It's impossible to focus on learning, on programming, on creating when you're holding it all day. So Teagan, Widmer actually created an open-source project that's called Refuge Restroom. And this is a project that has just a listing of either gender-neutral restrooms or safe restrooms. And this is an example of a community that's underserved that's doing their own thing. So if you are a web developer, or if you just want to add a safe restroom to the website, I suggest you check it out. So we've talked a little bit about homeostasis, about how you get your body to just function correctly. But what does homeostasis mean for a geek? I would posit that for a geek, homeostasis is de-packed mode. Homeostasis is that time when you can sit down and you're on your computer, the world melts away, and you can just focus on whatever you're passionate about. So what's the need? What do geeks need to be able to get into de-packed mode? Well, we need on interrupted time, we also need some sort of computer to be able to work on, and we also need electricity to power said computer, and maybe an internet connection to share your work, or at least to get the latest updates. So let's talk about each of these needs in detail. So a lot of developers complain, I don't have enough time, my manager interrupts me all the time, and I really can't get into de-packed mode. But for a certain set of people, time is actually uninterrupted time, is actually a very very precious commodity, and that's the people who are carers, the people who care for young children, or who care for elderly relatives, and this is important to think about, because women, and especially women of color, are much more likely to be carers. They're much more likely to not have the luxury of uninterrupted time. Actually, 59 to 75 percent of women are caregivers to either children or elderly relatives, and women of color are even more likely to be carers, and part of that may be due to the pay gap, because women of color can't afford child care, and so they, because they make, women of color, makes 55 percent of a white man's salary. So it's interesting to think about this, when we assume, as open source developers, that people are going to put so much uninterrupted time into our projects. We have to think about who are we discriminated against by assuming that people have this time. And how can we help them? How can we help the people who have maybe a little, only little chunks of time, to still contribute to our projects? And there are several different ways we can do that. If you run a conference or you run an event, think about whether you can provide child care, and you can actually get people to be able to bring their kids, drop them off, and then participate in an uninterrupted hack session. Do you, and then if you're looking at hiring, and I know that I am actually guilty of this, whenever I look at someone, and I want to hire them, and I know that they're going to work on an open source project. I say, I go and look and I see, what are their contributions? Do they have a GitHub account? Do they have patches upstream? Have they actually sent anything? But the people who are carers are actually more likely to not have extensive commitments, to not have an extensive GitHub, or maybe not have one at all. So when you're looking through resumes for people to go and work on an open source project, think about that, and maybe don't lay aside the ones that you know may be minorities that don't have a GitHub account. There's also a bunch of companies that are providing non-standard ways to get into tech. So in particular, the PayPal Recharge Program has a bunch of job listings that they're encouraging women who have taken a break to get back into tech. So maybe they took a break because they wanted to raise their kids until they were old enough to go into daycare or maybe even school, and these, this program is bringing them back. There's also, there's a pilot at Etsy where they are doing, giving executive coaching to new moms. So for that brief period of time, where the moms are coming back to tech, and they maybe need a mentor to talk about, like, how do I juggle my time commitments? They're giving them that coach. So it's interesting to think about, like, how can we mentor the carers in our society that are coming back into tech? You can also, there's something small that each of you could do. So how can we, as open-source contributors, help the people who have very little time that is uninterrupted? We can give them little chunks of tasks to do. We can add beginner tasks to our bug zillas and our to-do list trackers. We can go and we can add small little tutorials to Open Hatch, which is a way for contributors to do little missions and learn more about your project and get the skills that they need to gain to be a good contributor. There's also mother coders as well, that helps women who are mothers who are in tech. So let's talk a little bit about the second part of D-PAC mode, the second need, which is a need for a computer, and in in the US, I think a lot of us assume that everyone has a computer, and that's that's actually pretty close to being true. In 2013, 84% of households owned a computer. However, when you look at the numbers for who owns a computer, there's a giant racial disparity. From 1984, when the US Census first started tracking the number, to 2013, there's continued to be a racial disparity on which households own a computer. So African-American and Latino households are much less likely to own a computer. And if you look at the income differences on who owns computer, there's an even broader disparity. So the low income and the lowest class typically don't have computers. It's starting to get better, but you can't assume that they do. Also, this is just household computer ownership data. If you think about a particular household, there's a pecking order on who gets technology. Who gets technology first? It's the dad. Who gets technology second? Brother. Who gets technology last? Sister, mother, grandmother. So even though 84% of US households own a computer, the women in the household do not necessarily have access to that computer. There's a book that's entitled Women Don't Ask, and in that they interviewed a bunch of CS undergraduates who are part of the Carnegie Mellon University, and they found that they had these stories. They were trying to figure out why these women didn't know and didn't start programming until they got to college, and they found that the women had similar stories. The computer was in my brother's room. My dad hogged the computer all the time. I had a very limited amount of time on the computer because my brother was needed to do his homework on it. So when you think about who has computers, and you think about in your open source project, who has computers, you have to also think about what kind of computer they have. Now the people who are in lower-income situations and the people who are in different racial demographic, they might not be able to buy the fastest computer ever. They're not going to buy the highest-end thing. They might be buying something off of Craigslist. If they do buy something new, it's probably going to be two gigahertz, two gigs of RAM, and it's probably going to be a Chromebook. So when you think about as an open-source project, what are your minimum requirements to be a developer? Are you assuming that their computer can run in a virtualized environment? How much hard drive space are you actually taking up? And we as people in tech who own nice computers don't think about this. And so it's something that I would challenge you to try to think about in your own projects. So the other thing that you can do as an open-source project is maybe set up a sandbox server. So let people push their changes to a development server, run all the tests, compile it for them, and give them that virtualized environment on a server rather than forcing them to set it up on their own laptop. And that actually eases them into their project because there's less to set up. There's less of a barrier of entry. There's also a bunch of different organizations that give computers to underserved minorities in the US and also internationally as well. So Kids on Computers is one of the people, one of the people in the booth here, and they have done a bunch of different computer labs all running Linux in places like Latin America and Nepal. There's also computer reach in Portland. There's FreeGeek as well as in Chicago. And the Raspberry Pi team has been working to try to get very cheap computers to people around the world. So there's many different ways. And I know that each of you has that laptop that's sitting at home, you've gotten a new one, and you're just keeping it around just in case. I would really recommend you think whether you're actually going to use it. And if not, please donate that. So let's talk a little bit about the next need, the very basic need, to run a computer, which is electricity and internet. And in the US, I think that we really think of the US as a giant, giant presence online. However, when you look at the potential for growth in who is getting on the internet in the next couple of years, it's China and it's India. And in India alone, over a billion users are expected to come online. But they don't have internet as we know it. Typically, the internet they have is 2G cellular network. Because in India, in 2011, only 67% of households actually had electricity. They simply do not have the infrastructure to run the wired internet. So that means that most people, 19% of Indians, are on mobile networks. Well, only 1% are on wired networks. And that's a lot of people. And the important thing to note about this is since they're on mobile networks, they pay for everything, every single bit byte they download. And in general, a 500 megabyte plan for the average minimum wage worker in India costs 17 hours of pay. Think about that. If you break it down and you look at the average bandwidth for the average number of clicks on the internet, 15 clicks on the internet is equal to one Indian worker's one hour of pay. It takes 10 clicks for a new user to create a bug in Launchpad. As open source projects, we need to think about the impact we're having on the bandwidth of the people who are paying for the internet, for whom the internet is not free. So for the Floss projects, I'd really encourage you to think about how can we reduce our development footprint for the users who are on unreliable internet access. If you're a project that has documentation, please, for the sake of deity, ship with your documentation. Don't assume that the user is going to click on the internet to go access your documentation. Because most people will install a computer, come home, and then turn off the internet because they don't want their applications to unintentionally use up their precious data. So ship with your docs, please. There's also, in the open source community, I think we really like IRC, and we're also moving to Slack as well. But when you are hopping on and off the internet to save data, then that means that you lose the communications. You'll drop off IRC. So for open source projects, I would really, really urge you to consider asynchronous communication. So please, use a bug tracker, use the mailing list. There's also an open source project to replace Slack that's called Matters Most. And so I would encourage you to check that out as well. For tools, open source tools as well, there's a lot of tools that don't handle unreliable network connections. So if you download the Linux kernel today, it is 500 megabytes. That is one week of an Indian user's pay to download that. Now, the problem is, Git does not handle unreliable connections. If you drop, if you switch cell towers and your IP address change, you have to go redownload that 500 megabyte thing, a week's worth of pay. And there are flags in Git that you can use to save the objects to a particular directory instead of just throwing them away and then to reuse them when they restart. But they're not standard and they're very hard to find. So I would urge you that if you're making a tool, make sure that it can handle these unreliable internet connections. And if you're a web developer, a website developer, think about, can I detect a slow internet connection? And can I do something more interesting to fall back? Could I not show images? And that's actually what the Chrome developers have done. They've developed a plug-in that when you're on an unsecure connection, HTTP, they will actually not download the images to your phone. However, that only works over unsecure connections because Google has to be able to know you're downloading an image. How can we give people both security and the ability to control how much bandwidth they're using? So that is my challenge to you. So we've talked a whole lot about homeostasis and that's because it's the most basic level and there's a lot of different needs in there. So we're going to talk next a little bit about the next level, which is security. Now, I'm not going to argue that online harassment doesn't happen. I'm not going to argue about how prevalent harassment in our communities is. Instead, we're going to go through a little statistics experiment. So here we have an open-source community, a theoretical open-source community. And it's got 80% male developers and 20% female developers. Now, for the sake of imagination, we are going to assume that men and women are equally sexist. So in this community, we have eight misogynists, which are dictated by the green squares. And we have two misandrists, which are dictated by the yellow squares. So these are the toxic people in your community. So we'll go through, we'll also assume that the sexist people in the community have an equal opportunity to be sexist to everyone. So here we have a man being sexist to a woman, and then the interactions go on, we'll go around the circle, and the woman makes a sexist comment to a man. So let's go through 70 interactions and see how this little community plays out with an equal number of sexist men and women. What happens is the men in the community often don't see sexism at all. The women in the community, the luckiest women in the community, gets four sexist comments. And this is simply because of the gender ratio in the community. So this is actually called the p-tree multiplier. If you have a ratio, a gender ratio in a community, of one to r, women receive r to the two times as many sexist remarks as the men in the community. This also holds true for any minority in your community. If you have a minority that's mostly made up of cis people and has 20 percent trans men and women, and they will assume equally transphobic or cisphobic, then you will still get this same sort of thing. It holds true of religious minorities, of people who are LGBT. This holds true. So what does this mean for us? First of all, it means that when a minority in your community speaks up and says, I see sexism, I see racism, I see homophobia, you should believe them even if you do not see it yourself. Because as a minority in your community, they're much more likely to see it and experience it. The other thing that you should take away from this is that one bad actor in your community disproportionately impacts the minorities in your community. So anytime you find yourself saying, oh, that's just so-and-so, think about the impact they're having not just on the person, this one little interaction. Think about the impact they are having on all of the minorities in your community. So one of the ways that we can tell people in our community that bad behavior is not acceptable is a code of conduct. And there are a lot of different communities that I've seen adopting codes of conduct. But what I fear is that they see it as some sort of magical check mark. It's a magical check mark, this rainbow community code of conduct that will bring maidens to my community. Code of conducts are not magic check marks. You need to be able to enforce your code of conduct. What will you do when you have an incident? How will you handle it? What are the repercussions for someone who misbehaves? Because if there are no repercussions for bad behavior, you are giving a false sense of security to the minorities in your community who join because of the code of conduct. My recommendation as well is that you don't try to roll your own code of conduct. I've seen many communities and they're like, I'll take this code of conduct and that code of conduct and we'll mash them together and we'll add a little bit more that applies to our particular community. In open source, we don't roll our own cryptography. We should not roll our own code of conduct because if something goes wrong, we have given a false sense of security to the minorities in our community who are relying on it who will not feel safe. So I would really encourage you to pay people who are experts who have actually done code of conduct enforcement to help you with your own code of conduct and with setting up a base of leadership that can handle incidents. So some of the people that can do that are Safety First PDX. They run the open source bridge which is a highly inclusive conference and they've had to deal with code of conduct violations. So they've written up a blog post on how if your community is thinking about taking on a code of conduct, the steps that you should take. Other people you can pay for advice of how to increase diversity in your community include Ash Dryden and Frameshift Consulting as well. And these are women in tech that you can pay to help increase diversity. So I would highly encourage you to do so. So we've talked a little bit about security and code of conducts are fine and they make people feel more secure and maybe cut down on some of the harassment in your community. But as I mentioned, they're not a magic check mark. They're not going to increase diversity in your community just by having a code of conduct. So let's talk a little bit about community. So if you're trying to get more diversity in your community, but 90% of new contributors to your community fail to make a contribution, how can you expect the diverse people that are coming into your community to succeed? So maybe you need to look at your onboarding. How is the experience for the people who are newcomers to your community? How good is your onboarding? Is your documentation old and out of date? Maybe you just let new users go explore on their own. Because you know, everyone else figured it out, right? So in order to increase diversity in your community, you need to focus as well on finding mentors and also making better documentation because you want those people to succeed. And there's a lot of different ways that you can do that that I've listed on the slide that I'm not going to go into and you can read it later because I'll post the slides. Also, I'll post this. Any resources will also be mentioned in the slide notes and they'll be a URL at the end. So let's talk a little bit about esteem. Esteem is basically when your achievements are recognized by your community, by conference speakers, however you get praise. And in order to gain esteem and recognition, there needs to be an invitation. There needs to be opportunities. There needs to be an open door. But sometimes you've got to open the door yourself. And this is especially true of minorities. We're less likely to hear about opportunities because of unconscious bias, because of people seeking out ideas, leaders, people that look like them, even though there may be qualified candidates around them. We look for the people and the ideas that match our preconceived notions, that match our unconscious bias, that match our privileges. So unless we seek people outside our network, we're not going to increase diversity. In America, in general, only 75% of Americans have an African American friend. And most of them only have one friend. So when you think about that, think about how you can reach outside your network and give opportunities to people who may not look like you. And I think in open source communities, we tend to let long-standing contributors in our community shoulder a lot of the responsibilities and the burdens. And often, that leads to those long-standing contributors getting a little burned out when we really should be focusing on growing new contributors and new leaders within our communities. So I urge you to think about how do you do succession planning? If you're a maintainer, you know how difficult it is to take a vacation because the bugs keep coming in. And if you're working on something like the Linux kernel where security or safety is prominent, sometimes you're not able to take a vacation. What would happen if you had a backup maintainer who was able to take over while you took a vacation and learn the skills that were necessary so that if someone got hit by a bus, the project could continue? So it's something to think about. And as you do that, what you'll find is that you often have to document those tribal skills, the leadership skills, like how do I do a release? How do I figure out which bugs to look at first? How do I interact with users to get the information I need? So it's these leadership skills that often go undocumented because we don't have time as people who are leaders. But I urge you to do so because if you're not finding the next person who is going to take over after you, if you're not documenting how you do your work, there is the chance your project will die. So think about that. And as you try to find maintainers to take over for you, you should reach outside your network to find them. Try to reach out so that we can get more diverse leadership. And even if you're not a maintainer, even if you're not a full open source contributor, I would urge you to grow your network outside of the people who look like you. Go seek out diverse perspectives. Take a look at your own social network. How white is it? How male is it? Maybe go find those diverse voices to follow. But when you do, I ask one thing of you. Do not ask for education from minorities. Do not ask for that. If they give it, thank them for it, amplify that message. But you need to educate yourself about what it means to be a minority in tech and how to increase diversity in tech. And there are a lot of different resources that you can find out there, but it's not a minority's job to find them for you. When you go and you expand your network, try to amplify the voices and the accomplishments of minorities in your network so that we can gain that esteem within open source communities. So let's talk a little bit about the last level of Maslow's hierarchy of needs. Self-actualization. So self-actualization is the ability to be able to reach your fullest potential. And for some people, what that might be very different. So what are you passionate about? Do you want to do art? Do you want to do music? Do you want to be an open source contributor? Do you want to write Java? Do you want to be a DevOps person? What is your goal in life? And for some people, their goal, their passion is helping others reach their fullest potential. So you have people that are working on trying to make sure that minorities get postdocs. And you have people who are trying to make sure that women of color get involved through code for progress. You have people that are trying to work with open hatch to introduce newcomers to open source. You have people who are really passionate about free software freedom and also minority internships. So work for SFC or they do outreach internships or they're a community leader. These people are trying to help other people gain their fullest potential. And they've started projects to help with that. But you don't have to start some sort of grand project to help minorities in tech. We've talked about a bajillion different little things that each of you can do as an individual and as a community member to help out and increase diversity. You can donate your computer. You can look at your project's bandwidth and its minimum system resources and try to minimize that for the people who don't have a good internet connection. You can write documentation. You can mentor. You can amplify voices in your community. So I'd like to end with a little story that illustrates Maslow's hierarchy of needs. And remember in the beginning we said that each of the levels of needs needs to be met before the next one can be focused on. And so this is my story of how I started out in tech. So when I was a kid, my dad introduced me to my first computer. And it was a packered bell. And it had a turbo light. And it had a dial-up modem. And I would sing the song of the modem as I was getting on the internet to go play with Neopets. And it was my dad that introduced me to hardware hacking. So one day he brought home a sound card for the packered bell computer. And it was like a sound blaster or something, piece of crap. And he put it in the computer. And I remember I was sitting there and I was playing my favorite game, which was Might and Magic. And I was like, dad, dad, dad, the computer's talking. My game is talking to me. And it was so exciting to me that you could add this piece of hardware to the computer. And suddenly it was so much more awesome. And so that set me down the path of working on systems programming. Where you write software to talk to the hardware and do something cool. And so it was really my dad who was an ally who helped me learn about computers. And so I decided to go off to college. And I went to Portland State University. And I was doing a computer engineering degree. And I met a young man named Jamie, who later became my husband. And it was Jamie who helped me with my frustration with my CS classes. And it was Jamie who really gave me a safe place to learn. He didn't take away the keyboard. And if I was lost or frustrated, he would use socratic questioning methods to ask questions to get me to all the little points along the way that showed where I had missing information. What does this function do? What did you think it was going to do? Well, where could it have gone wrong? And he was really the one that taught me the critical thinking skills to be a programmer. And so again, this was an ally. This was someone who was helping me meet my need for a secure and safe place to learn. And it was through Jamie. And it was also through a person named Andrew Greenberg who got me involved in my first open source community. By this point, I had been using Linux for a while. I dual booted my laptop. But I hadn't ever contributed to open source. I'd never been a part of a community. So Andrew ran the Portland State Aerospace Society, which is an open source rocket group. And they are awesome. And it's very much an open source community where everyone is off doing their own thing. We've got one goal. But some people are working on motors. Some people are working on the airframe. Other people are working on an open source GPS. And everyone is trying to come together to reach the goal of getting a rocket into space and having a CubeSat go around the earth. And so it was Andrew that really introduced me to how to contribute within a team, within a community. And I worked on bigger projects on my own within a team. I worked on a USB sensor node project. And so it was actually Bart Massey who noticed the project and said, well, what if you worked on this interesting USB kernel project? Because I know the USB kernel maintainer. And so I worked on a project called USB FS2 with the USB maintainer, Greg Crow Hartman. And it was really Bart who gave me some coaching on how to gain a steam in the open source community, how to submit patches, how to give talks at conferences. And through my first conference talk, I was able to get a job at Intel working on providing USB 3 support for Linux. But without that push from my ally Bart to do a conference talk, I wouldn't be here today. And I spent a lot of time in the Linux kernel community. And I ended up doing a lot of really technically awesome things. But after a while, I wanted to help others. I wanted to help others be the best that they could be in tech. And so I started looking for something that would a project that would help me do that. And it was actually Karen Sandler who approached me and said, we have this internship program. And used to have an old name, but it's called Outreachy now. And it's an internship program that gives internships to minorities in the open source communities. So women and in the US people of color. And so she said, well, hey, could you be a coordinator for a project? Could you take the Linux kernel and try to get interns to work on the Linux kernel? And I said, okay, I foolishly said I will be a program coordinator under Outreachy. And it was a lot of work because it was wrangling mentors. It was answering questions. It was trying to make sure that the interns had their mail configuration right. Awful, awful things. And so it was a lot of tutorial writing. But it was wonderful because I got to interact with these newcomers who were so excited to work on this project that I was passionate about. And it was so fun to watch them get their first passion. And they're like, yes, I did it. And then from there they went on and they would do awesome complex projects that even I wouldn't understand. And so it was so nice to give someone that start and watch them fly. But when I did this program, after I had done it for maybe one round, I got really frustrated because I was afraid that I was bringing these women into a community that was toxic. And so I began to speak up about some of the harassment and verbal abuse that I had seen in the Linux kernel community. And there were a lot of community members that made me feel unsafe. There were community speakers who tried to turn the incident with Linus Torvalds into a joke. There were people in my community who told me, no, I think everyone should be able to say anything to anyone else because we shouldn't have to bottle up our emotions. Which implied that my emotions, as someone that had something toxic and vile spewed at them, did not matter. I had well-meaning women in my community say, you are pissing off powerful men. And that could be detrimental to your career. So I basically had the choice. I could continue and have job security and face the potential for verbal abuse in my community or I could leave and I could find a new community. And so that is what I did. I went and I found a new community in the Linux graphics community. And this is a story that is very common to minorities in tech because we often have to make the choice between safety and job security. And so as you go and you try to help increase diversity in tech, I urge you to think about Maslow's hierarchy of needs because you cannot help minorities succeed in your community unless all of their needs for security and their needs for geek homeostasis, computer, internet access is also net as well. So think of this as a framework to be able to decide in my community what do I need to focus on first in order to increase diversity. But I urge all of you to remember what you said at the beginning of the talk. Improving diversity in open source communities is your responsibility. Don't be a bystander. Thank you. All right. Thank you very much, Sarah. As a token of our appreciation, big surprise. I feel like I'm joining a soccer team now. Soccer team of awesome conference speakers. All right. And as I said, if you want to look at any of the resources, studies in the slides, then that URL at the bottom will bring you to that page which may or may not be live right now. Thank you. And I'll be answering questions out in the hall if you want to talk to me afterwards. All right. So as I said, we have two items to give away and we're going to try this, see how it works. Under two chairs, there are two tickets hidden. Oh, I don't get one. That's okay. Somewhere. There might not be enough chairs. You might have to check the chairs around you. It should literally right under the chair. No, like underneath. Someone stole it. No one found the ticket? Tickets? No. It's a golden ticket. Okay. We'll figure this out. All right. So for anyone that came in late, just a couple of announcements that I made, the HAM testing and the HAM radio testing and the LPI and BSD testing will be in ballrooms I and J. The schedule change, the 3 p.m. session which is in ballroom F has been canceled. So the 4 30 p session by Amy has been moved up. Thank you guys for coming and enjoy the rest of the day.