 So, I'm going to talk about open source and how to survive it, the open source survival guide. This is going to be a little bit different than the other talks I've given, and I'm extraordinarily nervous, especially going first, so, yeah, everyone get drunk, so I'm not so awkward. I myself don't drink, and so I'm going to enjoy a nice cup of mug root beer, which is not good. All right, so this is me, my name is Mike Moore, show of hands, who has been to Ruby on Ales, who is, this is their first Ruby on Ales? Are you kidding me? You guys have never, wow, that is amazing, welcome. I love Ruby on Ales, I've spoken here a couple of times, and this is a picture I always use, this is me, my name is Mike Moore, my handle everywhere is Blomage, I don't care how you say it. Last year I gave a talk, and in that talk I established that I'm a pretty big deal. And if you were here last year, you would be like, oh no, another one of these talks, and I'm not, and also this is also like a retreaded pun from last year, but don't worry, just deal with it, everything's going to be fine. That's my last pun actually, so it's going to be a little bit of a different talk. This is Rainbow Dash holding a beer, which is also on my awesome shirt that I printed by myself. I love this picture, and in my mind, like, I'm the one injecting my little pony into this, no one else ever does it, but I love this picture so much, I want to petition that we add the MLP beer emoji to the Slack channel, everybody should be on Slack. So if you can go on to the lounge right now, I want everybody to really hammer the organizers to please add this emoji, because I would like to use it a lot for the rest of this conference. It's fantastic, I love it. So I was originally going to talk about open source software and give lots of tips and tricks. I'm going to do kind of the same thing, but it ended up being a little bit different. I've gone to conferences and had speakers stand up and say like, oh, I completely rewrote my talk in the last two days. I haven't done that, but I feel like I'm doing that. So my expectations are a little bit different. So forgive me for having different expectations that you had no idea that I had. For the past 18 months, I have been a full-time, gainfully employed, productive member of society working on open source software. Ask me anything. And I am not kidding. I actually want you guys to ask me questions in the middle of the talk, because I think that would be awesome, and I've never seen that before. So I think we should do that. Some examples of questions you can ask are, how did you get that gig? And the answer is, I've got really good friends who pointed, people were looking to hire someone full-time in my direction. Another question you might ask is, why is your beard so magnificent? It's a valid question. I use beard oil and I comb it. I comb it a lot, and that's actually what makes it look really good. So whenever you see the AMA slide, I actually want you guys to ask me questions. It would be nice if they were related to the talk, but you can ask me something that's unrelated to the talk, which would also be awesome. So please do that. The airspeed of an unladen swallow? Man, I'm so nervous I can't even remember. 7, 42, I think. That's right. Is Europeans valid? Damn it, I'm terrible at this. OK, so I actually am going to talk about surviving open source. In my mind, there are three types of open source users. We have maintainers who are contributing to the libraries that we're all using. They're the ones who are managing it. We've got collaborators, people who are contributing to that as well. And then we've got consumers. And most of us are consumers, and a few of us are collaborators, and a very few are actual maintainers that spend all their time working on open source software. But this separation is good to know, because we're going to talk about how these different groups relate to each other. And depending on who you are and what you're using, you're going to be someone in these groups. And I've been members of all of these groups. OK, the other thing I want to talk about, who here is familiar with the Dreyfus model of skill acquisition? Like 12 people. Fantastic, that's good. That means that I'm actually going to give you something that you didn't know before, which is always a worry of mine. This is the Dreyfus model of skill acquisition. It basically, the Dreyfus model was identified or some researchers in the early 80s tried to figure out why people act differently based on their skill level. And they broke this down into five different groups. At the bottom, you have the novice group. And then as you gain more experience, you move up the group. So you go from novice to competence, competence to proficiency, proficiency to expertise, and expertise to mastery. So I've always, when I first learned of it, I also learned of it. My wife is a nurse. And we talked about a lot about how nurses behave, right? When she was straight out of nursing school, she was a novice. She didn't know anything. She was very intimidated. She didn't want to mess up. Didn't want to kill anybody. And so she had her list of duties that she was supposed to do on her rounds. And she followed them to a T, right? She made sure that she was working off exactly what was happening, made sure that everything that was on her list of things to do that she needed to do. She didn't question it. She accepted it. She did it. That's kind of the novice approach, right? This rote approach. So yeah, so rigid adherence to the taught rules. Not really. There's no discretionary judgment. You're following the rules. We all do this when we're learning something new for the first time. As you become more and more experienced, you move on to competence. And competence is you start to establish some limited situational perspective or perception. And you're still kind of treating all aspects of your work as important. There's it's hard to judge which is actually important, which is not as important. You're still kind of following the rules. In her case, she was still making sure that she was checking off the list of duties at the end of her shift. But she wasn't only going off of that. She kind of had started to internalize the things that she was doing on her rounds. Level three, get more proficient is proficiency. You start, they say, coping with crowdedness, right? You start to understand there's more things that you need to do that you're not necessarily able to do them all. And so you're going to respond to that a little bit differently. And you start to realize that what you're doing relates more to goals and less to tasks. And then you start to formulate your own routines instead of just going off of the routines that people give you. As you move into expertise, now you have this holistic view of what exactly you're trying to do. Your tasks are fulfilling that view of what you're trying to do. And you start to diverge at this point from the rote exercises, right? You're not necessarily, you're not even aware of the list anymore. You're still doing most of them, but you're starting to go a little bit different. And then the thing is with nurses, you get these masterful nurses. They behave very, very differently than brand new nurses, right? The things that they're doing, they're pattern matching on their experience, not on the list of tasks. So if there's somebody who's addicted to pain medication, they can tell they're addicted to pain medication. They know that they're probably going to be very manipulative and bargaining. They're going to treat that patient a lot differently than they would a brand new nurse who's just going to take everything at face value. If they see a family that is way too involved in what's going on, they know they're going to have to manage that family as well as manage the patient. And they're going to do this by feel. They're not really going to be thinking about it. They're going on instinct at this point. They've internalized their job so well that they're not going on a preconceived list of what they're doing. They're going completely on feel. And when you start going on feel, you're not doing everything on that list. You're doing a lot of things that are off of that list. And some things you're doing are even specifically forbidden from that list. And that's the Dreyfus model of skill acquisition. You can read a lot more about this in Andy Hunt's fantastic book, Pragmatic Thinking and Learning. You should all pick this up, because it's absolutely truly fantastic. Gets into how you learn and how you can hack yourself to learn better. So please go read this. Now let's take a look at, oh, Amy, ask me anything. I need a question. Yes? Can I buy you a t-shirt? Can I make you a t-shirt? No, this is this. I found this on the internet. I stole this, and so I printed it myself. And I don't have the copyrights to this, so no, I can't. But here's what you can do. You can go and find it on DeviantArt and then go to a digital screen printer and then buy your own shirt. So cut out that middleman. Excellent. Any other questions? Why Rainbow Dash? Why Rainbow Dash? Because she's 20% cooler. She's 55% cooler? No, she's 20% cooler. I like Rainbow Dash. Everyone has their preferences. What software do you work on? What software do I work on? I work for a very, very large technology company that you've all heard of on their cloud software, Ruby Libraries, so there you go. I'm not sure if I should really talk about it, but yes, that's what I do. Hold on to that. We have more questions. What? Yeah, if you know who Aja works for, then you can piece that together really fast. All right, so back to it. I actually do have points I'm trying to make in this talk. There are three types of users of open source software. You have maintainers, you have collaborators, and you have consumers. All right, let's talk about something else. Let's talk about documentation. I sent out a survey to a bunch of people of various levels of expertise and experience in open source and asked, what are the main problems that either you've experienced or that you see people coming into open source? What problems do they have? And I would like to share some of those problems. Chris Smith said, the absence of a progressive, smooth learning resource that has no sudden jumps and complexity, that's a blocker for a lot of people. Joshua Richardson says, if the documentation is bad or partially complete, it can be tough to understand or implement, which is also true. I keep hearing I should start with supplementing the documentation, but how does this even work? That says Barrett Clark. Todd Resdick says, you find the right solution, but it isn't documented well enough to understand, right? You may have found what you're actually looking for, but if it's new documentation, you have no idea of making that judgment if it is actually what you've been looking for. Sometimes the documentation assumes a certain level of expertise or of knowledge. It would be, I would like to see more how-to's and step-by-step examples, says Todd Thorley. John Jensen says, lack of support and documentation. Sarah May added, finding documentation not written by experts who assume context, they don't have, right? I like that one. And then Shingwe Su says, people who are big names and open source and who you looked up to, treating you like crap, which is not actually a documentation issue, but we'll get back to why that's there at the end. Because it kind of is a documentation issue. So documentation is a big issue in open source. Over the past 18 months, I have become convinced that this is the preeminent issue we have in open source. We have a documentation problem, especially in the Ruby community, right? So when people go look for documentation, I found that they typically go look at a GitHub page because we're a diverse set of experienced software developers with different opinions and views on the world and we've all decided that GitHub is a sole location, we're gonna put everything. There's no one central location for all documentation of all the gems, other than rubydocs.info, so we have to live with the yard view of our doc on there. But mostly we end up reading source code, which can be very daunting if you're new. So follow with me. If you're a consumer, you're very new, you don't know what to do, you end up going through all those things and realizing like wow, none of this is giving me what I need. The rubydocs.info has no information on actually how the library is supposed to be used, even the method calls that are listed, there's no context for when you're supposed to use them, so I'm going to read the source code and now I have to become an expert in this library, expert enough to understand what it is in order to use it and that's a very difficult journey. So in code, these type of documentation we tend to have in code. We describe what the methods are, we sometimes describe what arguments the method takes, we should do a lot more of that and then even more rarely, we actually have an example code of how to call it. These are all incredibly important and something that we're lacking today. There's another type of documentation that we have. The readme is probably the, again, look at the GitHub page, we see the readme, that's the first thing we want to see. Unfortunately a lot of times the readme is not geared for that type of person, for the consumer who just wants to understand is this a viable option for me, right? They're not given that information in the readme. Or hopefully sometimes there's tutorials, there's step-by-step instructions, that can be in a blog post, it can be somewhere else, there's also screencasts and books, right? Most open source libraries are missing all of these things and that's unfortunate. The easiest thing to solve is the readme, right? The one thing we can do, all of us when we are on a project is make sure that the readme solves the problem that most consumers have. They basically, they want to know what it does and what it doesn't do. They want to know if it's the right fit. They want a simple code example to get an idea about how complex the library is to use. Installing the library is usually a gem and so they'll probably know that already but it's not bad to also have that there as well. And then pointers to where the longer form documentation is. Where's the code documentation? Where's the guides? Where's the more information that they're gonna have? How do they get help, right? So I think we can all improve. I think most gems that I use can improve in this way, right? To me, the first and foremost responsibility of the readme is to help people understand if this is the right thing. It's not to describe the library from its perspective. It's not self-identifying the library. It's to give consumers the ability to know if this is something that they want to use. All right, it's incredibly difficult to do. The reason it's difficult is because of empath, empathy, sorry, empath. Yeah, it's difficult. The reason it's difficult, remember that dry scale of scale acquisition, we have those five different levels. Typically the people that are maintaining the software, they're at that highest level. And I have found that you can teach one level down of those five levels. Maybe if you're really good, you can go too. But if you're at that mastery level and you're trying to appeal to novices, it's nearly impossible to go down through all five layers to talk to them. Because you miss out on the empathy. You are optimizing going so much on feel, so much on your own intuition that it's just impossible to understand how they are viewing it. What are the things? Who, I've been in software for a long time, so I have a hard time remembering how difficult and frustrating it was starting out. I just do, right? I try, but it's not something that's just very deep in the core of me anymore. I've lost that. But what that does mean is that we have a grand opportunity. When you do come to an open source library that is missing documentation, you've gone through the effort of understanding it to the point that you can actually use it, you're one step away from contributing back that information in the form of documentation. And the number one problem with open source is documentation. Ask me anything. Yeah. A good example of a readme. That's a great question. What's a good example of a readme? I don't have one offhand. I mean, I can find some, I'll look at some later. I don't have one off, I wish I would have, I would have been prepared if I would have done that. I started my slides 24 hours ago. Who else had a question? Yeah. Examples of well-documented libraries. So I think it's, it's actually not even a Ruby library, but React Redux, which is like a implementation of the flux architecture. They have a book, right? They actually wrote an ebook. And if you want to understand like, what React Redux is supposed to do, you're not going to look at the library because you look at the library, you're going to find the implementation. You want to find like, what's the concepts? Like, how do you know if you're using it well versus just hacking something together and using a library, not as is intended? So they wrote a book and they've got lots of different contributors, you know, making that book better every single day, right? So I love the idea of starting a book. And it doesn't have to be a book. You can do a screencast, you can do just long-form blog posts, you know, stuff like that. So, yeah. Oh, so has there been a library that has made a turnaround going from port documentation to great documentation that has not originated from the maintainers? I haven't. I'm a recent convert to documentation 18 months ago. I was like a necessary evil that you kind of had to do, but I've really come around. I really do view this important, but that's also been driven by myself and Chris Smith who I work with. So we'll go there right here. A good style of documentation. Well, technical writing, right? That's the style that I'm most familiar with for documentation. I spent a semester in communications in college and this was at the early, early days of the web and I really was interested in how you convey information online. So for me, that's just one of those things that is so deeply embedded in my experience as a programmer is so it's right there with, you know, how the web works is the idea of technical documentation. So it's hard for me to like, you know, give you resources on our 21-year-old textbooks from college. But yeah, they're there, but I would look for technical documentation because people don't read, they skim. So you want things that people can like pull out and like focus on and then actually read, right? They're looking for an answer when they are skimming. So you want to format it in such a way, bullet lists and everything so that they can find what they're looking for quickly. Yeah. Mentorship is the best practice for knowledge transfer. Should we be looking for mentorship for documentation? Absolutely 100% yes. The person I work with, his name is Chris Smith, Quartzmo on Twitter. He is a master of documentation. He's really helped me understand the importance of this. So I've been mentored by him for the past nine months and that has absolutely helped. Yeah, you can pair a program on anything, right? You can pair on anything. It doesn't have to be programming. One more, right here. How do you assess that you know enough as a new developer to be able to submit documentation? That's a great question as I move on to the next slide. Three types of developers, right? In open source. People who maintain libraries, people who collaborate, contribute to libraries and people who consume libraries. So let's talk about contributing. Oh no, there we go, all right, iPhone. Let me look at my notes real quick because I'm unprepared. So yeah, once you've understood a library that wasn't well documented, you have a tremendous opportunity because it is so fresh, right? You almost can't go wrong, right? Because anything you contribute is going to be a point of view that maintainers are not gonna have, right? So when do you know enough? When you know how to use it. That's when you know that you have enough, right? That's not to say that your contributions are gonna be perfect. It's not to say that you're gonna know exactly how to contribute, but it's a grand opportunity, right? We can solve one of the biggest problems if we do this, you know? We compare what the documentation story is with our own experience and then try to identify filling gaps and take notes as you're going along. So there are lots of types of contributions. Mostly we focus on code, right? We focus on I'm gonna write some code, I'm gonna do a pull request and they're gonna accept it and I'm an open source contributor and you know, Amy everybody's gonna, you're gonna be famous and everything's gonna be fantastic and you never have any problems again in the rest of your life. But documentation I think is most important. Documentation is usually the first way that you contribute, but I don't wanna discount, I think almost as equally as important is organizational contributions. When I first started, I ran a conference for 10 years and last week was the last, the 10th and the last conference. When I started, I did not have a job in Ruby, I was an enthusiast. My contributions up until that point were organizing user groups and doing conferences. I actually didn't have a job using Ruby at all. I just loved it so much and I loved the community and I'd gotten so much mentorship from the community I wanted to give back. And so that's a really, really valuable contribution that you can make, right? So if you look at this list, like I don't know if I can contribute documentation because I don't know that I understand it well enough and I don't know if I can contribute code, well you can contribute organizational support as well. So find a way to contribute. That's the thing I would like to leave you guys with. So code, almost by necessity, consumers are left out of code contributions mostly because if you can contribute code, then you're gonna be a collaborator, right? You're that, but you can do organizational stuff. So don't discount that. Oh, he's amulet. Okay, there's things we can do to contribute or to encourage first time contributors. Add a contributing file to your repo and go through this. Explain to people who are just starting how you set up your developer environment, right? Do you require a certain version of Ruby? Are you expecting, are you using Bundler? Like you should document that. You should put that in your contributing guide. But also explain how you wanna be contacted. Do you want people just to create new features and submit them in pull requests or do you want them to contact you first, right? Do you want to discuss whether or not feature was a good idea before they actually started doing work on it? How do you set up your environment to run tests? What's your testing library like that? What dependencies you have as well, right? Do you depend on the database? Do you depend on something else? And then also code conventions because there's nothing better than writing code and then being told like, oh, can you like reformat your code because I don't like it. It seems arbitrary. And if you documented those, you can avoid that. In fact, another conversion I've come to late is RuboCop. I hate RuboCop, to no end. I really, really, really despise RuboCop but it helps save arguments because if we define what the style is, if it passes RuboCop then we don't question it. We don't have that fight. So setting up RuboCop is actually really good. If you care at all about style then automate that as much as you can. It's the same as automating tests. If you care about the correctness of your code you're gonna automate that in tests. If you care about style, automate it with RuboCop. Make sure you've got an automated build that also runs your style linter, right? So they submit a pull request, it runs, it fails. Why? Because they didn't run the linter and they didn't know that we don't like parentheses where it's not needed. You can add issues to your GitHub repo that identify issues that are great for first time contributors, right? Here's an idea, here's some documentation. You wanna add an argument to this method, an optional argument, well label that up and then encourage people to submit it for the first time. If you've got a more sophisticated environment you can use something like Docker or Vagrant to install that for you and make it a lot easier to get up and running and contributing quickly. All right, ask me anything. Yeah, does development style affect the documentation? Like how you're building your code? Does that affect documentation? I think it does and the example was like the read me driven development. I'm a test driven developer and so I always think about the design of the code before we implement because that's what I write tests against. The thing that I've learned is that that separation and I call it like code documentation versus like guide documentation, that's the big divide, right? Because one is this is what it does and this is why it does it. And that I think is that understanding was huge for me and I don't know if development style really will affect that, right? But you could do that, you could go out and instead of being like a read me first you say we're gonna actually write the book, we're gonna write this design document about this is how we're gonna solve problems with software and figure out how you're gonna solve all those UI problems, user experience problems with code and then use that to build the library off of, right? You could do that. One more question. Oh, so what are some best practices on using the first time issues? Lots of open source projects use it, Mozilla was the example of creating them. There are actually multiple web apps that will track GitHub repos and you can configure what label that you're gonna add and so you can go and get like a more holistic view of here all the things that have been identified for new users. I think there's a lot of innovation going on actually in that right now. Really it's just choose a label and then don't be so quick to close it, like let it sit there for a couple months and see if you can really encourage people to do it. The other thing is some repositories will label things as we will only accept a fix for this from a first time contributor. Like you've never contributed to the project before or you've never done an open source pull request before. And then they put resources around that to encourage people to do it as well. All right, I'm late. I had so much more that I wanted to go through and I cut it out because I wanna get to where I'm gonna end up here. Three types of users, maintainers, collaborators, consumers. Each one has different responsibilities for contributing to software. All right, surviving software. He said the word, that's in the title. So when I started, I was really kind of taken away with the promise of open source. I love the idea of the democratization of information. There's no other term of phrase I haven't heard my notes. The idealistic optimism about technology, right? Like that was fantastic. I loved it and maybe I'm showing my age. But now I think that a lot of people view open source as like a quagmire or a dangerous place. Like there are things that can hurt you in that. So how do you survive in this world? Because I've seen the open source world change a lot in the last 20 years. So I wanna talk just a little bit about that. One great tool for surviving open source is user groups. And Tsing Wei Su said that she founded and organized a meetup group that was specifically designed for people who were new, right? And it was specifically around welcoming new folks, right? So here's what we can do with the help. Here's how we can survive with the help of user groups. Just be active in one, find your user group, right? Be involved. I've benefited so much more from user groups than I've contributed. And I say I'm a lot and I just realized. Find a beginner friendly user group or create one. That's a fantastic idea. And then, again, organize a user group. You don't have to start one, you don't have to be the leader, but you can still affect the user group. One of the things that my look at user group did, we had my first pull request night. People had never made a pull request, never contributed to open source. We went out and we identified a bunch of projects that had issues and it may have been they were missing their license declaration and their gem spec or something, right? We went out and we helped them go through step-by-step and submit a pull request to fix that. It was simple, it was really easy. Go find those first-time issues and walk people through the process of how you contribute. Eileen, you should tell, says that asking about like contributing that she doesn't know that you can learn a lot of this beforehand. A lot of open source knowledge just comes from contributing. You're gonna make mistakes, you're gonna get frustrated, it's not gonna be easy. But if you remember that everyone is human and treat them as such, apologize when necessary and write good explanations, including commit messages, you will learn so much from contributing to open source and that's 100% true. Absolutely, especially true is that you kinda have to go through it first. The big thing that Eileen calls out here is all about communication and that is true. So let's talk a little bit about communication. Eileen also added that part of the problem with communicating the open source is that everything is remote, right? And the skills for learning how to deal with someone when you're remote is different than what you're doing face-to-face. You've gotta change how you write. That technical writing is actually very helpful here. I don't know, let's let go. Also, don't blame or ask maintainers for problems, right? That's a problem, who thinks that's a problem in open source? Who thinks that it's a problem the other way around? I've got two slides so far going both ways. Why is that? I wanna talk about something, it's a concept that is referred to as the box. This comes from a book that has changed my life called Leadership and Self-Deception. Has anybody heard of this book? Or heard of the box, okay? When I sat down and I came down to it, it's like, how do you survive open source? This for me has been the key. This is what it's kept me saying. I'm gonna introduce a couple of quick concepts about this book. It's all built around this idea of self-deception. Have you ever been in a relationship with someone, a friend, or whoever, and that relationship has just felt stuck, like it's not moving anywhere? Who has felt that before? Honestly, who has felt that, right? Should be all of us. That's the box. That's this idea of self-deception. So I've felt this, experiencing other people or circumstances as having more power over your own happiness than you do, right? I have 100% felt that. Have you ever been so convinced about something that you were right about something that it made you miserable, right? Conflict is gonna be unavoidable. But anxiety, suspicion, resentment, anger, that doesn't come from other people that comes from us. I said this online. I knew I shouldn't. I 100% did. I literally could not stop myself. I knew it was a mistake. I was unable to, right? This is not a great thing to say to someone, right? It's incredibly passive-aggressive. I didn't have the skills at the time to stop myself. And as it turned out, this wasn't a great thing to say and things escalated after I said it. All right, I'm late, aren't I? Am I over? Am I over? I'm gonna go real quick. Let's take an example. Let's say that we have an open source maintainer who is very stressed. He's got this, or he or she's got this open source project that takes a lot of their time and effort, right? Takes their attention away from their family and they're feeling pressure. They're feeling pulled because they feel a responsibility to the open source community, but they also feel a responsibility to their family and they're unable to resolve that. And so whenever they come to and look at their open source, there's a little bit of resentment there when issues come in. Okay, so that's the maintainer. On the contributor or the collaborator side, let's say you've got someone who is trying to use the software, they're going through the documentation. It doesn't give them the information they need. They figure out that it's just broke. It just doesn't, Flatout doesn't work and they lost eight hours of their time trying to get something to work. And they just want to just eviscerate the person, open an issue, but they don't. They open an issue and say, your software Flatout doesn't work, you should fix it, right? The maintainer, right, they come to that, they get the notice, they look at their phone, they open up their browser, they read the issue. It doesn't work. All right, then they have to explain, all right, well, can you reproduce how it doesn't work? What are you trying to do? Like, do I really have to go and tease this information out of you and you're just like the last 100 people that have done this to me, right? And it takes time and effort and mental energy that I just don't have anymore, right? So maybe they get defensive and they're like, screw you, right? It works, you don't know what you're doing. Okay, does that situation seem plausible to anybody? Okay, why is that? And my phone is out. All right, what you're doing is you've got this story about yourself, about who you think you are and you project that in all of your interactions with other people. The user, they were trying to do their best. They were so frustrated and upset at the maintainer for wasting their time that they really wanted to lay into them, but they didn't. And they're like, oh, I'm the virtuous one because I didn't tell you exactly what I thought, right? And then the maintainer, they're like so overwhelmed with everything, you know, they can't maintain that empathy. And so they're trying to like tease out information but they don't have it in them anymore. They're both trying to do the right thing but they both sabotage each other, right? It's this vicious cycle. What happens is we end up looking at other people, not as people, we look at them as objects, we look at them as problems or we look at them as an opportunity to get something out of them. We don't look at them as people anymore. We look at them as we dehumanize them in ourselves. And you can see how both these parties did that. They dehumanized the other person and they were already at war before they even talked to each other. This is the box. This is what self-deception leads to. When you behave in a way that you know is incorrect, deep in your heart, you will justify that. You will make that be someone else's problem. They're the one causing it. I'm not behaving correctly, but it's because of them. It's their fault, right? You have a distorted interpretation of what others are doing and then you have a distorted interpretation and an interpretation of what you're doing back to them, right? And you are the box at this point. Terry Warner, I love this quote. When someone we have been blaming becomes real to us, we change. We become a person who sees another person as real. We change from being accusing, guarded and self-absorbed to being open, self-forgetful and welcoming. I know the culture I want to live in and I know the culture that some people experience and they're both reflective here. This notion of self-deception, this notion of being in the box about how we view others and how they feed on our view of ourselves, that's the real problem. When you see someone in a conflict online, they're both showing exactly who they think they are deep in their hearts. So if we go back in the time machine, how could either party have avoided that situation, right? The maintainer, they could have been like, wow, this person is in pain. I've done something to cause them pain, right? They're not being very open and sharing. Instead of viewing it as an attack, they view it as a signal that that person's in pain, right? So the user has the box, maintainer has the box. If that maintainer is able to just step aside out of the box and see this interaction from a third party view, they're like, oh wow, that person's in pain. Let's actually get to the root cause of why they're projecting what they're projecting. On the user side, they can do the exact same, right? Maintaining open source is very difficult, is very demanding. So maybe we could be a little more sympathetic to that. I'm gonna skip through this. Here's some examples of what you can do to try and get that to happen. The point of this is that software, at its essence, is a cooperative game. It succeeds when we cooperate together. You have to get outside of yourself, you have to accept other people as they are. Even if you're flawed, even if they're flawed, you can still do it in a way that does not escalate. You can still do it in a way that you can bridge the gap and that you can really connect with the actual human being behind their behavior, okay? When you do that, being wrong isn't scary, right? Yeah, I'm sorry you feel that way, that was wrong. It's a lot easier for me to admit that now because I've got this framework. This is how I view online interactions. My goal, my hope, is that we can be open, truthful, compassionate, and helpful. And that's the essence of how you survive open source software. Ask me anything. Ryan. I am not wearing shoes because they flop around and they feel uncomfortable. And I'm like being very earthy and hippy, it's Utah, or it's Oregon. I'm from Utah originally so I'm like trying to hipster out. What's that? Your talk is gonna be better than mine, but it couldn't hurt. Oh, so Aja at Mountain West last week did this wonderful thing where you ask a question and then she shows another picture and so I'm gonna show animated gifts for every picture from now on. Another question. Kobe, I'm way over. I'm really sorry about that. I'm not in a question for you. Question, has your stress level working on open source versus private? I've been remote for a really long time so in a lot of ways my work style has been the same. The stressors on me are not so much about the work. It's more about burnout and managing my own internal stuff so I don't see open source being that tremendously different than working with everyone else but that's because I'm remote. If I was in an office every day working face to face with people I would have developed a much different set of skills over the past five years that would probably not help me as much when doing open source. So remote is the future. Learn how to work remotely. That's how you're gonna succeed. Yeah, back in the back. I'd rather take the time to talk to 10 people about the right way to approach and fix a problem or what? And they never actually finish it or would you rather have someone submit a pull request and just have them do it the wrong way? I feel like I'm an outlier here. What I would like is I would like someone contacting me and saying I have an idea and I'd be like, fantastic, let's pair program on that, right? Because I love pairing and I would like to do online pair programming with more people online, so. That was a good question. Next. Questions. What do you use to pair program online? ScreenHero is great. You don't have to have dual control. So something like Hangouts or Skype will work. I'm actually going to be doing a startup. I'm gonna bootstrap a startup this year that is gonna try and help online pair programming. So, you know, what's for that? Great question. I've got a few more, so a couple more questions. Tips for what? Tips for working remotely. You have to change your communication style, a lot more asynchronous and then also you have to be better at writing, right? And I also, you talk a lot, right? You actually, you're doing ScreenHero or you're doing Hangouts or whatever. You're actually talking to them, you're just not doing it in person. But yeah, they shouldn't go by when you're not actually face-to-face with somebody remotely, okay? I have two more, no, actually three. Question. Is it possible people can't work remotely? Oh, that they can't learn? No, anybody can learn anything. Yeah, but you can learn it. It might be difficult, but you absolutely can learn. I mean, we're, I don't know, we're, I don't wanna get religious, but like, we're inherently royalty. Like, you know, if we come from a God, we can learn anything, right? So, no, like, there is no limit, you know? Your progression can go on for a long time. So, you're not stuck, ever. Good question. All right, this one's funny. One more, yeah, right. So, how do you go from, how do you go from, how do you move up the level of skill acquisition or give them on? Well, everyone's on the novice, you know, I mean, that's how the model works. People will help, can do that themselves. Like, they will seek out information, but you should never look more than one level above you. You should look to peers or people that are the one level higher and look for help. If you reach all the way at the top, you're gonna have a bad time. Just the same as if you try and reach down too far, you're gonna have a bad time. You can do it, but it takes a lot of effort to overcome that. So, just look for people that are just one or two steps ahead of you and use them, right? And then also help people that are around you. That's what I would say. All right, I think this is the last one. This is my favorite. Last question. Sorry. What's that? Oh, how do you convince people who are not into open source that you should do open source? I was in IT for a long time, like large enterprise IT, and I tried for a good decade of my career to move them. And I'm convinced you can't. I'm convinced that if you're in a group that doesn't want to value open source, that you can't move them, and so you should move. And that's a hard answer to give, but that's the truth of it, is that you're just kicking up against a brick wall at that point. So yeah, if you like where you're at, but they're not meeting some need, then go find someplace else that will meet that need. So I'm super late. I'm sorry to the organizers. I do this every year. I arrive in Oregon with no slides. But I know, why do they do that? Here's the thing. Here's the thing. When it came down to it, I thought what's the absolute most important thing that I can share with you? This is the most meaningful thing to me, right? That you have to treat each other well, and that starts with you, right? So this really truthful, honest assessment of yourself, and then being very forgiving and open of other people, and you can do it. It's right there. So I read the books, and thank you very much. Appreciate it.